Intelligent network

ABSTRACT

A network intelligence system may include a plurality of sensors located throughout and industry system. The sensors may obtain data related to various aspects of the industry network. The network intelligence system may include system endpoint intelligence and system infrastructure intelligence. The system endpoint and system infrastructure intelligence may provide distributed intelligence allowing localized decision-making to be made within the industry system based in response to system operation and occurrences. The network intelligence may include a centralized intelligence portion to communicate with endpoint and infrastructure intelligence. The centralized intelligence portion may provide responses on a localized level of the system or on a system-wide level.

CLAIM OF PRIORITY

This application claims the benefit of priority of U.S. ProvisionalPatent Application Ser. No. 61/315,897 filed on Mar. 19, 2010 and U.S.Provisional Patent Application Ser. 61/201,856 filed on Dec. 15, 2009,both of which are incorporated by reference. This application is acontinuation-in-part of U.S. patent application Ser. No. 12/378,091filed on Feb. 11, 2009, which claims priority to U.S. Provisional PatentApplication Ser. No. 61/127,294 filed on May 9, 2008 and U.S.Provisional Patent Application Ser. No. 61/201,856 filed on Dec. 15,2009. This application is also a continuation-in-part of U.S. patentapplication Ser. No. 12/378,102 filed on Feb. 11, 2009, which claimspriority to U.S. Provisional Patent Application Ser. No. 61/127,294filed on May 9, 2008 and U.S. Provisional Patent Application Ser. No.61/201,856 filed on Dec. 15, 2009. U.S. Provisional Patent ApplicationSer. No. 61/201,856 and U.S. patent application Ser. Nos. 12/378,091 and12/378,102 are incorporated by reference.

BACKGROUND

1. Field of the Invention

The present invention relates generally to a system and method formanaging an industry network, and more particularly to a system andmethod for collecting data at different sections of the industry networkand analyzing the collected data in order to manage the industrynetwork.

2. Related Art

Various industries have networks associated with them. The industriesmay include utilities, telecommunication, vehicle travel (such as airtravel, rail travel, automobile travel, bus travel, etc.), and energyexploration (such as oil wells, natural gas wells, etc.).

One such industry is the utility industry that manages a power grid. Thepower grid may include one or all of the following: electricitygeneration, electric power transmission, and electricity distribution.Electricity may be generated using generating stations, such as a coalfire power plant, a nuclear power plant, etc. For efficiency purposes,the generated electrical power is stepped up to a very high voltage(such as 345K Volts) and transmitted over transmission lines. Thetransmission lines may transmit the power long distances, such as acrossstate lines or across international boundaries, until it reaches itswholesale customer, which may be a company that owns the localdistribution network. The transmission lines may terminate at atransmission substation, which may step down the very high voltage to anintermediate voltage (such as 138K Volts). From a transmissionsubstation, smaller transmission lines (such as sub-transmission lines)transmit the intermediate voltage to distribution substations. At thedistribution substations, the intermediate voltage may be again steppeddown to a “medium voltage” (such as from 4K Volts to 23K Volts). One ormore feeder circuits may emanate from the distribution substations. Forexample, four to tens of feeder circuits may emanate from thedistribution substation. The feeder circuit is a 3-phase circuitcomprising 4 wires (three wires for each of the 3 phases and one wirefor neutral). Feeder circuits may be routed either above ground (onpoles) or underground. The voltage on the feeder circuits may be tappedoff periodically using distribution transformers, which step down thevoltage from “medium voltage” to the consumer voltage (such as 120V).The consumer voltage may then be used by the consumer.

One or more power companies may manage the power grid, includingmanaging faults, maintenance, and upgrades related to the power grid.However, the management of the power grid is often inefficient andcostly. For example, a power company that manages the local distributionnetwork may manage faults that may occur in the feeder circuits or oncircuits, called lateral circuits, which branch from the feedercircuits. The management of the local distribution network often relieson telephone calls from consumers when an outage occurs or relies onfield workers analyzing the local distribution network.

Power companies have attempted to upgrade the power grid using digitaltechnology, sometimes called a “smart grid.” For example, moreintelligent meters (sometimes called “smart meters”) are a type ofadvanced meter that identifies consumption in more detail than aconventional meter. The smart meter may then communicate thatinformation via some network back to the local utility for monitoringand billing purposes (telemetering). While these recent advances inupgrading the power grid are beneficial, more advances are necessary. Ithas been reported that in the United States alone, half of generationcapacity is unused, half the long distance transmission network capacityis unused, and two thirds of its local distribution is unused.Therefore, a need clearly exists to improve the management of the powergrid.

Another such industry is the vehicle travel industry. The vehicle travelindustry generally relates to the management of the movement of one ormore types of means of transportation, such as an airplane, train,automobile, bus, etc. For example, the train industry includes raillines, trains that run on the rail lines, a central control, and anetwork to control the rail lines/trains. The network may include thesensors to sense the various parts of the rail lines, the means by whichto communicate to/and from the central control, and the means by whichto control the rail lines. Typically, the network for the rail industryis primitive. Specifically, the network limits the type of sensors used,the means by which to communicate to/from the central control, and theability to control the rail lines. Therefore, a need clearly exists toimprove the management of the rail lines.

BRIEF SUMMARY

An intelligent network for improving the management of an industrysystem is provided. The intelligent network may be customizable andapplied to the one or more industries. Examples include applications tothe utility industry and vehicle travel industry (such as air travelnetwork, rail travel network, automobile travel network, bus travelnetwork, etc.). The intelligent network may also be customized andapplied to a telecommunication network and to energy exploration.

An intelligent network may include one or more system endpoints. Thesystem endpoints may include one or more endpoint sensors to monitorvarious conditions of an industry system and generate data indicative ofthe conditions. The system endpoints may include endpoint analytics toprocess system endpoint data and generate any appropriate decisionsbased on the data.

The intelligent network may include a system infrastructure includingone or more infrastructure sensors to monitor various conditions of theindustry system infrastructure and generate data indicative of theconditions. The system infrastructure may include infrastructureanalytics to process the data and generate any appropriate decisionsbased on the data. The system infrastructure may also receive data fromthe system endpoints to generate appropriate decisions.

The system endpoints and system infrastructure may generate event dataindicative of an occurrence of interest within the industry system. Thesystem endpoints and system infrastructure may also generate operationaland non-operational data indicative of the industry system. Theintelligent network may include one or more buses to provide event dataand operational/non-operational data to a network core of theintelligent network. The network core may include system analytics toanalyze received data and generate decisions that may be localized orglobal within the industry system. The network core may also include adata collection used to store received data in order to retrieve forsubsequent review and analysis. The network core may also include systemcontrols used control various aspects of the system industry. The systemcontrols may be implemented when various decisions have been made andmay require system manipulation. The intelligent network may alsoinclude an enterprise system in communication with the network core.

Other systems, methods, features and advantages will be, or will become,apparent to one with skill in the art upon examination of the followingfigures and detailed description. It is intended that all suchadditional systems, methods, features and advantages be included withinthis description, be within the scope of the invention, and be protectedby the following claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-C are block diagrams of one example of the overall architecturefor a power grid.

FIG. 2 is a block diagram of the Intelligent Network Data Enterprise(INDE) CORE depicted in FIG. 1.

FIGS. 3A-C are block diagrams of another example of the overallarchitecture for a power grid.

FIG. 4 is a block diagram of the INDE SUBSTATION depicted in FIGS. 1 and3.

FIGS. 5A-B are block diagrams of the INDE DEVICE depicted in FIGS. 1A-Cand 3A-C.

FIG. 6 is a block diagram of still another example of the overallarchitecture for a power grid.

FIG. 7 is a block diagram of still another example of the overallarchitecture for a power grid.

FIG. 8 is a block diagram including a listing of some examples of theobservability processes.

FIGS. 9A-B illustrate flow diagrams of the Grid State Measurement &Operations Processes.

FIG. 10 illustrates a flow diagram of the Non-Operational Dataprocesses.

FIG. 11 illustrates a flow diagram of the Event Management processes.

FIGS. 12A-C illustrate flow diagrams of the Demand Response (DR)Signaling processes.

FIGS. 13A-B illustrate flow diagrams of the Outage IntelligenceProcesses.

FIGS. 14A-C illustrate flow diagrams of the Fault Intelligenceprocesses.

FIGS. 15A-B illustrate flow diagrams of the Meta-data ManagementProcesses.

FIG. 16 illustrates a flow diagram of the Notification Agent processes.

FIG. 17 illustrates a flow diagram of the Collecting Meter Data (AMI)processes.

FIGS. 18A-D are an example of an entity relationship diagram, which maybe used to represent the baseline connectivity database.

FIGS. 19A-B illustrate an example of a blueprint progress flow graphic.

FIG. 20 is block diagram of an example intelligent network.

FIGS. 21A-21C is a block diagram of one example of the overallarchitecture for INDE architecture.

FIG. 22 is a block diagram of the INDE CORE depicted in FIG. 21.

FIGS. 23A-23C are block diagrams of another example of the overall INDEarchitecture.

FIGS. 24A-24C are block diagrams of an example of the INDE architectureimplemented in a rail network.

FIG. 25 are block diagrams of an example train in the INDE architectureof FIGS. 24A-24C.

FIGS. 26A-26C are block diagrams of an example of an example of the INDEarchitecture implemented in an electric rail network.

FIGS. 27A-27C are block diagrams of an example of the INDE architectureimplemented in a trucking network.

FIGS. 28A-28C are block diagrams of an example of the INDE architectureimplemented in an automobile network.

FIG. 29 is an example operational flow diagram of the INDE architectureof FIG. 20.

FIG. 30 is a block diagram of an example of multiple INDE architecturesbeing used with one another.

DETAILED DESCRIPTION OF THE DRAWINGS AND THE PRESENTLY PREFERREDEMBODIMENTS

By way of overview, the preferred embodiments described below relate toa method and system for managing an industry network. Applicants provideexamples below related to various industry networks, such as utility andvehicle travel networks (such as air travel network, rail travelnetwork, automobile travel network, bus travel network, etc.). However,other industry networks may be used including a telecommunicationnetwork, and an energy exploration network (such as a network of oilwells, a network of natural gas wells, etc.).

As discussed in more detail below, certain aspects relate to a utilitynetwork, such as the power grid itself (include hardware and software inthe electric power transmission and/or the electricity distribution) orthe vehicle travel network. Further, certain aspects relate to thefunctional capabilities of the central management of the utilitynetwork, such as the central management of the power grid and thecentral management of the vehicle travel network. These functionalcapabilities may be grouped into two categories, operation andapplication. The operations services enable the utilities to monitor andmanage the utility network infrastructure (such as applications,network, servers, sensors, etc).

In one of the examples discussed below, the application capabilities mayrelate to the measurement and control of the utility network itself(such as the power grid or vehicle travel network). Specifically, theapplication services enable the functionality that may be important toutility network, and may include: (1) data collection processes; (2)data categorization and persistence processes; and (3) observabilityprocesses. As discussed in more detail below, using these processesallows one to “observe” the utility network, analyze the data and deriveinformation about the utility network.

Referring now to FIG. 20, a block diagram illustrating an exampleIntelligent Network Data Enterprise (INDE) architecture 2000 that may beapplied to industry systems of various industries is shown. In oneexample, the INDE architecture may include a network core 2002. Thenetwork core 2002 may receive various types of information and/or databased the particular industry of use. Data and information for aparticular industry may originate at a system endpoint 2006, which mayrepresent various points with an industry system. Each system endpoint2006 may include a number of endpoint sensors 2014 that may detectvarious conditions associated with an industry system. For example, theendpoint sensors 2014 may be dedicated to detecting power line flow in autility grid or arrival/departure issues of an airline. Each of thesystem endpoints 2006 may include one or more processors and memorydevices allowing localized analytics to be performed. In once exampleendpoint analytics 2016 may determine various events based on datareceived from the endpoint sensors 2006.

The INDE architecture 2000 may also include a system infrastructure2008, which may support the system endpoints 2006 throughout theindustry system. The system infrastructure 2008 may includeinfrastructure sensors 2022 distributed throughout the industry systemto detect conditions associated with the industry system. In oneexample, the system infrastructure 2008 may include infrastructureanalytics 2020 allowing the system infrastructure to analyze the datareceived from the infrastructure sensors 2022.

The network core 2002 may receive information from the system endpoints2006 and the system infrastructure 2008. In one example, the INDEarchitecture 2000 may include a number of buses such as anoperational/non-operational bus 2010 and an event bus 2012. Theoperational/non-operational bus 2010 may be used to communicate bothoperational and non-operational data. In one example, operational datamay refer to data associated the various operations of a particularindustry system implementing the INDE architecture 2000. Thenon-operational data may refer to data in the industry associated withaspects concerning the particular industry system itself. The event bus2012 may receive data related to various events occurring in theindustry system. Events may refer to any occurrence of interest in theindustry system. Thus, events may include undesired or abnormalconditions occurring in the industry system.

The INDE architecture 2000 may implement distributed intelligence inthat various components of the architecture may be used to process dataand determine an appropriate output. In one example, the endpointanalytics 2006 may include one or more processors, memory devices, andcommunication modules to allow processing to be performed based on datathat is received by the endpoint sensors 2006. For example, the endpointanalytics 2016 may receive data from the endpoint sensors 2014 relatedto an event and may determine that the particular event is occurringbased on the data. The endpoint analytics 2016 may generate anappropriate response based on the event.

The infrastructure analytics 2020 may similarly include one or moreprocessors, memory devices, and communication modules to allowprocessing to be performed based on data that is received by theinfrastructure sensors 2022. The system infrastructure 2008 maycommunicate with system endpoints 2006 allowing the systeminfrastructure 2008 to utilize the infrastructure analytics 2020 toevaluate and process the event data, as well asoperational/non-operational data from the system endpoints 2014 andinfrastructure sensors 2022.

Data may also be evaluated by the network core 2002 provided by thebuses 2010 and 2012. In one example, the network core 2002 may includesystem analytics 2024 that includes sensor analytics 2026 and eventanalytics 2028. The analytics 2026 and 2028 may include one or moreprocessors and memory devices allowing event data andoperational/non-operational data to be analyzed. In one example, thesensor analytics 2024 may evaluate sensor data from endpoint sensors2014 and infrastructure sensors 2022. In event analytics 2028 may beused to process and evaluate event data.

The network core 2002 may also include a data collection 2030. The datacollection 2030 may include various data warehouses 2032 used to storeraw and processed data allowing historical data to be retrieved asnecessary allowing future analytics to be based on historical data.

The network core 2002 may also include system controls 2034. The systemcontrols 2034 may be responsible for actions taken within in theindustry system. For example, the system controls 2002 may includeautomatic controls 2036 that automatically control various aspects ofthe industry system based on event data and/oroperational/non-operational data. The network core 2002 may also includeuser controls 2038 allowing human control over the industry system whichmay or may not be based on event data and/or operational/non-operationalbus.

An enterprise system 2004 may include various large-scale softwarepackages for the industry. The enterprise system 2004 may receive andtransmit data to the network core 2002 for use in such features such asinformation technology (IT) or other aspects related to the industry. Inalternative examples, the buses 2010 and 2012 may be integrated into asingle bus or may include additional buses. Alternative examples mayalso include a system infrastructure 2008 including various sub-systems.

Referring now to FIG. 29, an example operational diagram of the INDEarchitecture 2000 is shown. In one example, a system endpoint (SE1) 2006may determine an occurrence of an event E1. Another system endpoint(SE2) 2006 may determine an occurrence of an event E2. Each systemendpoint 2006 may report the events E1 and E2 via event data to thesystem infrastructure 2008. The system infrastructure 2008 may analyzethe event data and generate a decision D1 that may be transmitted to thesystem endpoints SE1 and SE2 allowing the system endpoints to implementthe response.

In another example, an event E3 may be determined by the system endpointSE1. The event data reporting the event E3 may be transmitted to thenetwork core 2002 allowing the network core 2002 to implement systemanalytics 2024 and generate a decision D2 via the system controls 2034.The decision D2 may be provided to the system endpoint SE1.

In another example, the system endpoint SE1 may determine occurrence ofan event E4 and notify the network core 2002 of the event E4 via eventdata. The network core 2002 may generate a decision D3 and provide itthe system endpoint SE1 for implementation, while providing informationregarding the decision D3 to the enterprise system 2004.

In another example, the system endpoint SE1 may determine occurrence ofan event E5. The system endpoint SE1 may implement the endpointanalytics 2016 to determine and subsequently implement a decision D4.The decision D4 may be provided to the system infrastructure 2008 andthe network core 2002 for notification and storage purposes. Theexamples regarding FIG. 29 are illustrative and other events,operational data, and non-operational data may be communicated throughthe INDE system 2002.

INDE High Level Architecture Description Overall Architecture

Turning to the drawings, wherein like reference numerals refer to likeelements, FIGS. 1A-C illustrate one example of the overall architecturefor INDE. This architecture may serve as a reference model that providesfor end to end collection, transport, storage, and management of utilitynetwork data (such as smart grid data); it may also provide analyticsand analytics management, as well as integration of the forgoing intoutility processes and systems. Hence, it may be viewed as anenterprise-wide architecture. Certain elements, such as operationalmanagement and aspects of the utility network itself, are discussed inmore detail below.

The architecture depicted in FIGS. 1A-C may include up to four data andintegration buses: (1) a high speed sensor data bus 146 (which in theexample of a power utility may include operational and non-operationaldata); (2) a dedicated event processing bus 147 (which may include eventdata); (3) an operations service bus 130 (which in the example of apower utility may serve to provide information about the smart grid tothe utility back office applications); and (4) an enterprise service busfor the back office IT systems (shown in FIGS. 1A-C as the enterpriseintegration environment bus 114 for serving enterprise IT 115). Theseparate data buses may be achieved in one or more ways. For example,two or more of the data buses, such as the high speed sensor data bus146 and the event processing bus 147, may be different segments in asingle data bus. Specifically, the buses may have a segmented structureor platform. As discussed in more detail below, hardware and/orsoftware, such as one or more switches, may be used to route data ondifferent segments of the data bus.

As another example, two or more of the data buses may be on separatebuses, such as separate physical buses in terms of the hardware neededto transport data on the separate buses. Specifically, each of the busesmay include cabling separate from each other. Further, some or all ofthe separate buses may be of the same type. For example, one or more ofthe buses may comprise a local area network (LAN), such as Ethernet®over unshielded twisted pair cabling and Wi-Fi. As discussed in moredetail below, hardware and/or software, such as a router, may be used toroute data on data onto one bus among the different physical buses.

As still another example, two or more of the buses may be on differentsegments in a single bus structure and one or more buses may be onseparate physical buses. Specifically, the high speed sensor data bus146 and the event processing bus 147 may be different segments in asingle data bus, while the enterprise integration environment bus 114may be on a physically separate bus.

Though FIGS. 1A-C depict four buses, fewer or greater numbers of busesmay be used to carry the four listed types of data. For example, asingle unsegmented bus may be used to communicate the sensor data andthe event processing data (bringing the total number of buses to three),as discussed below. And, the system may operate without the operationsservice bus 130 and/or the enterprise integration environment bus 114.

The IT environment may be SOA-compatible. Service Oriented Architecture(SOA) is a computer systems architectural style for creating and usingbusiness processes, packaged as services, throughout their lifecycle.SOA also defines and provisions the IT infrastructure to allow differentapplications to exchange data and participate in business processes.Although, the use of SOA and the enterprise service bus are optional.

In the example of a power grid, the figures illustrate differentelements within the overall architecture, such as the following: (1)INDE CORE 120; (2) INDE SUBSTATION 180; and (3) INDE DEVICE 188. Thisdivision of the elements within the overall architecture is forillustration purposes. Other division of the elements may be used. And,the division of elements may be different for different industries. TheINDE architecture may be used to support both distributed andcentralized approaches to grid intelligence, and to provide mechanismsfor dealing with scale in large implementations.

The INDE Reference Architecture is one example of the technicalarchitecture that may be implemented. For example, it may be an exampleof a meta-architecture, used to provide a starting point for developingany number of specific technical architectures, one for each industrysolution (e.g., different solutions for different industries) or one foreach application within an industry (e.g., a first solution for a firstutility power grid and a second solution for a second utility powergrid), as discussed below. Thus, the specific solution for a particularindustry, or a particular application within an industry (such as anapplication to a particular utility) may include one, some, or all ofthe elements in the INDE Reference Architecture. And, the INDE ReferenceArchitecture may provide a standardized starting point for solutiondevelopment. Discussed below is the methodology for determining thespecific technical architecture for a particular industry or aparticular application within an industry (such as a particular powergrid).

The INDE Reference Architecture may be an enterprise wide architecture.Its purpose may be to provide the framework for end to end management ofdata and analytics, such as end to end management of grid data andanalytics and integration of these into utility systems and processes.Since advanced network technology (such as smart grid technology)affects every aspect of utility business processes, one should bemindful of the effects not just at the network level (such as the grid),operations, and customer premise levels, but also at the back office andenterprise levels. Consequently the INDE Reference Architecture can anddoes reference enterprise level SOA, for example, in order to supportthe SOA environment for interface purposes. This should not be taken asa requirement that a industry, such as a utility, must convert theirexisting IT environment to SOA before the advanced network, such as asmart grid, can be built and used. An enterprise service bus is a usefulmechanism for facilitating IT integration, but it is not required inorder to implement the rest of the solution. The discussion belowfocuses on different components of the INDE smart grid elements for autility solution; however, one, some, or all of the components of theINDE may be applied to different industries, such as telecommunication,vehicle travel, and energy exploration.

INDE Component Groups

As discussed above, the different components in the INDE ReferenceArchitecture may include, for example: (1) INDE CORE 120; (2) INDESUBSTATION 180; and (3) INDE DEVICE 188. The following sections discussthese three example element groups of the INDE Reference Architectureand provide descriptions of the components of each group.

INDE CORE

FIG. 2 illustrates the INDE CORE 120, which is the portion of INDEReference Architecture that may reside in an operations control center,as shown in FIGS. 1A-C. The INDE CORE 120 may contain a unified dataarchitecture for storage of grid data and an integration schema foranalytics to operate on that data. This data architecture may use theInternational Electrotechnical Commission (IEC) Common Information Model(CIM) as its top level schema. The IEC CIM is a standard developed bythe electric power industry that has been officially adopted by the IEC,aiming to allow application software to exchange information about theconfiguration and status of an electrical network.

In addition, this data architecture may make use of federationmiddleware 134 to connect other types of utility data (such as, forexample, meter data, operational and historical data, log and eventfiles), and connectivity and meta-data files into a single dataarchitecture that may have a single entry point for access by high levelapplications, including enterprise applications. Real time systems mayalso access key data stores via the high speed data bus and several datastores can receive real time data. Different types of data may betransported within one or more buses in the smart grid. As discussedbelow in the INDE SUBSTATION 180 section, substation data may becollected and stored locally at the substation. Specifically, adatabase, which may be associated with and proximate to the substation,may store the substation data. Analytics pertaining to the substationlevel may also be performed at the substation computers and stored atthe substation database, and all or part of the data may be transportedto the control center.

The types of data transported may include operation and non-operationaldata, events, grid connectivity data, and network location data.Operational data may include, but is not limited to, switch state,feeder state, capacitor state, section state, meter state, FCI state,line sensor state, voltage, current, real power, reactive power, etc.Non-operational data may include, but is not limited to, power quality,power reliability, asset health, stress data, etc. The operational andnon-operational data may be transported using anoperational/non-operational data bus 146. Data collection applicationsin the electric power transmission and/or electricity distribution ofthe power grid may be responsible for sending some or all of the data tothe operational/non-operational data bus 146. In this way, applicationsthat need this information may be able to get the data by subscribing tothe information or by invoking services that may make this dataavailable.

Events may include messages and/or alarms originating from the variousdevices and sensors that are part of the smart grid, as discussed below.Events may be directly generated from the devices and sensors on thesmart grid network as well as generated by the various analyticsapplications based on the measurement data from these sensors anddevices. Examples of events may include meter outage, meter alarm,transformer outage, etc. Grid components like grid devices (smart powersensors (such as a sensor with an embedded processor that can beprogrammed for digital processing capability) temperature sensors,etc.), power system components that includes additional embeddedprocessing (RTUs, etc), smart meter networks (meter health, meterreadings, etc), and mobile field force devices (outage events, workorder completions, etc) may generate event data, operational andnon-operational data. The event data generated within the smart grid maybe transmitted via an event bus 147.

Grid connectivity data may define the layout of the utility grid. Theremay be a base layout which defines the physical layout of the gridcomponents (sub stations, segments, feeders, transformers, switches,reclosers, meters, sensors, utility poles, etc) and theirinter-connectivity at installation. Based on the events within the grid(component failures, maintenance activity, etc), the grid connectivitymay change on a continual basis. As discussed in more detail below, thestructure of how the data is stored as well as the combination of thedata enable the historical recreation of the grid layout at various pasttimes. Grid connectivity data may be extracted from the GeographicInformation System (GIS) on a periodic basis as modifications to theutility grid are made and this information is updated in the GISapplication.

Network location data may include the information about the gridcomponent on the communication network. This information may be used tosend messages and information to the particular grid component. Networklocation data may be either entered manually into the Smart Griddatabase as new Smart Grid components are installed or is extracted froman Asset Management System if this information is maintained externally.

As discussed in more detail below, data may be sent from variouscomponents in the grid (such as INDE SUBSTATION 180 and/or INDE DEVICE188). The data may be sent to the INDE CORE 120 wirelessly, wired, or acombination of both. The data may be received by utility communicationsnetworks 160, which may send the data to routing device 190. Routingdevice 190 may comprise software and/or hardware for managing routing ofdata onto a segment of a bus (when the bus comprises a segmented busstructure) or onto a separate bus. Routing device may comprise one ormore switches or a router. Routing device 190 may comprise a networkingdevice whose software and hardware routes and/or forwards the data toone or more of the buses. For example, the routing device 190 may routeoperational and non-operational data to the operational/non-operationaldata bus 146. The router may also route event data to the event bus 147.

The routing device 190 may determine how to route the data based on oneor more methods. For example, the routing device 190 may examine one ormore headers in the transmitted data to determine whether to route thedata to the segment for the operational/non-operational data bus 146 orto the segment for the event bus 147. Specifically, one or more headersin the data may indicate whether the data is operation/non-operationaldata (so that the routing device 190 routes the data to theoperational/non-operational data bus 146) or whether the data is eventdata (so that the routing device 190 routes the event bus 147).Alternatively, the routing device 190 may examine the payload of thedata to determine the type of data (e.g., the routing device 190 mayexamine the format of the data to determine if the data isoperational/non-operational data or event data).

One of the stores, such as the operational data warehouse 137 thatstores the operational data, may be implemented as true distributeddatabase. Another of the stores, the historian (identified as historicaldata 136 in FIGS. 1 and 2), may be implemented as a distributeddatabase. The other “ends” of these two databases may be located in theINDE SUBSTATION 180 group (discussed below). Further, events may bestored directly into any of several data stores via the complex eventprocessing bus. Specifically, the events may be stored in event logs135, which may be a repository for all the events that have published tothe event bus 147. The event log may store one, some, or all of thefollowing: event id; event type; event source; event priority; and eventgeneration time. The event bus 147 need not store the events long term,providing the persistence for all the events.

The storage of the data may be such that the data may be as close to thesource as possible or practicable. In one implementation, this mayinclude, for example, the substation data being stored at the INDESUBSTATION 180. But this data may also be required at the operationscontrol center level 116 to make different types of decisions thatconsider the grid at a much granular level. In conjunction with adistributed intelligence approach, a distributed data approach may bebeen adopted to facilitate data availability at all levels of thesolution through the use of database links and data services asapplicable. In this way, the solution for the historical data store(which may be accessible at the operations control center level 116) maybe similar to that of the operational data store. Data may be storedlocally at the substation and database links configured on therepository instance at the control center, provide access to the data atthe individual substations. Substation analytics may be performedlocally at the substation using the local data store.Historical/collective analytics may be performed at the operationscontrol center level 116 by accessing data at the local substationinstances using the database links. Alternatively, data may be storedcentrally at the INDE CORE 120. However, given the amount of data thatmay need to be transmitted from the INDE DEVICES 188, the storage of thedata at the INDE DEVICES 188 may be preferred. Specifically, if thereare thousands or tens of thousands of substations (which may occur in apower grid), the amount of data that needs to be transmitted to the INDECORE 120 may create a communications bottleneck.

Finally, the INDE CORE 120 may program or control one, some or all ofthe INDE SUBSTATION 180 or INDE DEVICE 188 in the power grid (discussedbelow). For example, the INDE CORE 120 may modify the programming (suchas download an updated program) or provide a control command to controlany aspect of the INDE SUBSTATION 180 or INDE DEVICE 188 (such ascontrol of the sensors or analytics). Other elements, not shown in FIG.2, may include various integration elements to support this logicalarchitecture.

Table 1 describes the certain elements of INDE CORE 120 as depicted inFIG. 2.

TABLE 1 INDE CORE Elements INDE CORE Element Description CEP Services144 Provides high speed, low latency event stream processing, eventfiltering, and multi-stream event correlation Centralized May consist ofany number of commercial or custom Grid Analytics analytics applicationsthat are used in a non-real time Applications 139 manner, primarilyoperating from the data stores in CORE Visualization/ Support forvisualization of data, states and event Notification streams, andautomatic notifications based on event Services 140 triggers ApplicationServices (such as Applications Support Services 142 Management andDistributed Computing Support 143) that support Services 141 applicationlaunch and execution, web services, and support for distributedcomputing and automated remote program download (e.g., OSGi) NetworkAutomated monitoring of communications networks, Management applicationsand databases; system health Services 145 monitoring, failure root causeanalysis (non-grid) Grid Meta-Data Services (such as ConnectivityServices 127, Name Services 126 Translation 128, and TEDS Service 129)for storage, retrieval, and update of system meta-data, including gridand communication/sensor net connectivity, point lists, sensorcalibrations, protocols, device set points, etc Grid Data/ Services(such as Sensor Data Services 124 and Analytics Services AnalyticsManagement Services 125) to support 123 access to grid data and gridanalytics; management of analytics Meter Data Meter data managementsystem functions (e.g., Management Lodestar) System 121 AMOS Meter Seediscussion below Data Services Real Time Message bus dedicated tohandling event message Complex Event streams—purpose of a dedicated busit to provide Processing Bus 147 high bandwidth and low latency forhighly bursty event message floods. The event message may be in the formof XML message. Other types of messages may be used. Events may besegregated from operational/non- operational data, and may betransmitted on a separate or dedicated bus. Events typically have higherpriority as they usually require some immediate action from a utilityoperational perspective (messages from defective meters, transformers,etc) The event processing bus (and the associated event correlationprocessing service depicted in Figure 1) may filter floods of eventsdown into an interpretation that may better be acted upon by otherdevices. In addition, the event processing bus may take multiple eventstreams, find various patterns occurring across the multiple eventstreams, and provide an interpretation of multiple event streams. Inthis way, the event processing bus may not simply examine the event datafrom a single device, instead looking at multiple device (includingmultiple classes of devices that may be seemingly unrelated) in order tofind correlations. The analysis of the single or multiple event streamsmay be rule based Real Time Op/ Operational data may include datareflecting the Non-Op Data current state of the electrical state of thegrid that Bus 146 may be used in grid control (e.g., currents, voltages,real power, reactive power, etc.). Non-operational data may include datareflecting the “health” or condition of a device. Operational data haspreviously been transmitted directly to a specific device (therebycreating a potential “silo” problem of not making the data available toother devices or other applications). For example, operational datapreviously was transmitted to the SCADA (Supervisory Control And DataAcquisition) system for grid management (monitor and control grid).However, using the bus structure, the operational data may also be usedfor load balancing, asset utilization/optimization, system planning,etc., as discussed for example in FIGS. 10-19. Non-operational data waspreviously obtained by sending a person in the field to collect theoperational data (rather than automatically sending the non- operationaldata to a central repository). Typically, the operational andnon-operational data are generated in the various devices in the grid atpredetermined times. This is in contrast to the event data, whichtypically is generated in bursts, as discussed below. A message bus maybe dedicated to handling streams of operational and non-operational datafrom substations and grid devices. The purpose of a dedicated bus may beto provide constant low latency through put to match the data flows; asdiscussed elsewhere, a single bus may be used for transmission of boththe operation and non- operational data and the event processing data insome circumstances (effectively combining the operation/non-operationaldata bus with the event processing bus). Operations Message bus thatsupports integration of typical Service Bus 130 utility operationsapplications (EMS (energy management system), DMS (distributionmanagement system), OMS (outage management system), GIS (geographicinformation system), dispatch) with newer smart grid functions andsystems (DRMS (demand response management system), external analytics,CEP, visualization). The various buses, including the Operation/Non-operational Data bus 146, the Event data bus 147, and the operationsService Bus 130 may obtain weather feeds, etc. via a security framework117. The operations service bus 130 may serve as the provider ofinformation about the smart grid to the utility back officeapplications, as shown in Figure 1. The analytics applications may turnthe raw data from the sensors and devices on the grid into actionableinformation that will be available to utility applications to performactions to control the grid. Although most of the interactions betweenthe utility back office applications and the INDE CORE 120 is expectedto occur thru this bus, utility applications will have access to theother two buses and will consume data from those buses as well (forexample, meter readings from the op/non-op data bus 146, outage eventsfrom the event bus 147) CIM Data Top level data store for theorganization of grid data; Warehouse 132 uses the IEC CIM data schema;provides the primary contact point for access to grid data from theoperational systems and the enterprise systems. Federation Middlewareallow communication to the various databases. Connectivity Theconnectivity warehouse 131 may contain the Warehouse 131 electricalconnectivity information of the components of the grid. This informationmay be derived from the Geographic Information System (GIS) of theutility which holds the as built geographical location of the componentsthat make up the grid. The data in the connectivity warehouse 131 maydescribe the hierarchical information about all the components of thegrid (substation, feeder, section, segment, branch, t-section, circuitbreaker, recloser, switch, etc— basically all the assets). Theconnectivity warehouse 131 may have the asset and connectivityinformation as built. Thus, the connectivity warehouse 131 may comprisethe asset database that includes all the devices and sensors attached tothe components of the grid. Meter Data The meter data warehouse 133 mayprovide rapid Warehouse 133 access to meter usage data for analytics.This repository may hold all the meter reading information from themeters at customer premises. The data collected from the meters may bestored in meter data warehouse 133 and provided to other utilityapplications for billing (or other back-office operations) as well asother analysis. Event Logs 135 Collection of log files incidental to theoperation of various utility systems. The event logs 135 may be used forpost mortem analysis of events and for data mining Historical Data 136Telemetry data archive in the form of a standard data historian.Historical data 136 may hold the time series non-operational data aswell as the historical operational data. Analytics pertaining to itemslike power quality, reliability, asset health, etc may be performedusing data in historical data 136. Additionally, as discussed below,historical data 136 may be used to derive the topology of the grid atany point in time by using the historical operational data in thisrepository in conjunction with the as-built grid topology stored in theconnectivity data mart. Further, the data may be stored as a flatrecord, as discussed below. Operational Data 137 Operational Data 137may comprise a real time grid operational database. Operational Data 137may be built in true distributed form with elements in the substations(with links in Operational Data 137) as well as the Operations center.Specifically, the Operational Data 137 may hold data measurementsobtained from the sensors and devices attached to the grid components.Historical data measurements are not held in this data store, insteadbeing held in historical data 136. The data base tables in theOperational Data 137 may be updated with the latest measurementsobtained from these sensors and devices. DFR/SER Files 138 Digital faultrecorder and serial event recorder files; used for event analysis anddata mining; files generally are created in the substations by utilitysystems and equipment

As discussed in Table 1, the real time data bus 146 (which communicatesthe operation and non-operational data) and the real time complex eventprocessing bus 147 (which communicates the event processing data) into asingle bus 346. An example of this is illustrated in the block diagram300 in FIGS. 3A-C.

As shown in FIGS. 1A-C, the buses are separate for performance purposes.For CEP processing, low latency may be important for certainapplications which are subject to very large message bursts. Most of thegrid data flows, on the other hand, are more or less constant, with theexception of digital fault recorder files, but these can usually beretrieved on a controlled basis, whereas event bursts are asynchronousand random.

FIG. 1 further shows additional elements in the operations controlcenter 116 separate from the INDE CORE 120. Specifically, FIG. 1 furthershows Meter Data Collection Head End(s) 153, a system that isresponsible for communicating with meters (such as collecting data fromthem and providing the collected data to the utility). Demand ResponseManagement System 154 is a system that communicates with equipment atone or more customer premises that may be controlled by the utility.Outage Management System 155 is a system that assists a utility inmanaging outages by tracking location of outages, by managing what isbeing dispatched, and by how they are being fixed. Energy ManagementSystem 156 is a transmission system level control system that controlsthe devices in the substations (for example) on the transmission grid.Distribution Management System 157 is a distribution system levelcontrol system that controls the devices in the substations and feederdevices (for example) for distribution grids. IP Network Services 158 isa collection of services operating on one or more servers that supportIP-type communications (such as DHCP and FTP). Dispatch Mobile DataSystem 159 is a system that transmits/receives messages to mobile dataterminals in the field. Circuit & Load Flow Analysis, Planning,Lightning Analysis and Grid Simulation Tools 152 are a collection oftools used by a utility in the design, analysis and planning for grids.IVR (integrated voice response) and Call Management 151 are systems tohandle customer calls (automated or by attendants). Incoming telephonecalls regarding outages may be automatically or manually entered andforwarded to the Outage Management System 155. Work Management System150 is a system that monitors and manages work orders. GeographicInformation System 149 is a database that contains information aboutwhere assets are located geographically and how the assets are connectedtogether. If the environment has a Services Oriented Architecture (SOA),Operations SOA Support 148 is a collection of services to support theSOA environment.

One or more of the systems in the Operations Control Center 116 that areoutside of the INDE Core 120 are legacy product systems that a utilitymay have. Examples of these legacy product systems include theOperations SOA Support 148, Geographic Information System 149, WorkManagement System 150, Call Management 151, Circuit & Load FlowAnalysis, Planning, Lightning Analysis and Grid Simulation Tools 152,Meter Data Collection Head End(s) 153, Demand Response Management System154, Outage Management System 155, Energy Management System 156,Distribution Management System 157, IP Network Services 158, andDispatch Mobile Data System 159. However, these legacy product systemsmay not be able to process or handle data that is received from a smartgrid. The INDE Core 120 may be able to receive the data from the smartgrid, process the data from the smart grid, and transfer the processeddata to the one or more legacy product systems in a fashion that thelegacy product systems may use (such as particular formatting particularto the legacy product system). In this way, the INDE Core 120 may beviewed as a middleware.

The operations control center 116, including the INDE CORE 120, maycommunicate with the Enterprise IT 115. Generally speaking, thefunctionality in the Enterprise IT 115 comprises back-office operations.Specifically, the Enterprise IT 115 may use the enterprise integrationenvironment bus 114 to send data to various systems within theEnterprise IT 115, including Business Data Warehouse 104, BusinessIntelligence Applications 105, Enterprise Resource Planning 106, variousFinancial Systems 107, Customer Information System 108, Human ResourceSystem 109, Asset Management System 110, Enterprise SOA Support 111,Network Management System 112, and Enterprise Messaging Services 113.The Enterprise IT 115 may further include a portal 103 to communicatewith the Internet 101 via a firewall 102.

INDE SUBSTATION

FIG. 4 illustrates an example of the high level architecture for theINDE SUBSTATION 180 group. This group may comprise elements that areactually hosted in the substation 170 at a substation control house onone or more servers co-located with the substation electronics andsystems.

Table 2 below lists and describes certain INDE SUBSTATION 180 groupelements. Data security services 171 may be a part of the substationenvironment; alternatively, they may be integrated into the INDESUBSTATION 180 group.

TABLE 2 INDE SUBSTATION Elements INDE SUBSTATION ELEMENTS DescriptionNon-Operational Performance and health data; this is a distributed DataStore data historian component 181 Operational Real time grid statedata; this is part of a true Data Store 182 distributed databaseInterface/ Support for communications, including TCP/IP, CommunicationsSNMP, DHCP, SFTP, IGMP, ICMP, DNP3, IEC Stack 187 61850, etc.Distributed/ Support for remote program distribution, inter- remotecomputing process communication, etc. (DCE, JINI, OSGi for support 186example) Signal/ Support for real time digital signal processingWaveform Processing components; data normalization; engineering units185 conversions Detection/ Support for real time event streamprocessing, Classification detectors and event/waveform classifiers(ESP, Processing 184 ANN, SVM, etc.) Substation Support for programmablereal time analytics Analytics 183 applications ; DNP3 scan master; Thesubstation analytics may allow for analysis of the real-time operationaland non-operational data in order to determine if an “event” hasoccurred. The “event” determination may be rule-based with the rulesdetermining whether one of a plurality of possible events occurringbased on the data. The substation analytics may also allow for automaticmodification of the operation of the substation based on a determinedevent. In this way, the grid (including various portions of the grid)may be “self-healing.” This “self-healing” aspect avoids the requirementthat the data be transmitted to a central authority, the data beanalyzed at the central authority, and a command be sent from thecentral authority to the grid before the problem in the grid becorrected. In addition to the determination of the “event,” thesubstation analytics may also generate a work-order for transmission toa central authority. The work- order may be used, for example, forscheduling a repair of a device, such as a substation. Substation LAN172 Local networking inside the substation to various portions of thesubstation, such as microprocessor relays 173, substationinstrumentation 174, event file recorders 175, and station RTUs 176.Security services 171 The substation may communicate externally withvarious utility communications networks via the security services layer.

As discussed above, different elements within the smart grid may includeadditional functionality including additional processing/analyticalcapability and database resources. The use of this additionalfunctionality within various elements in the smart grid enablesdistributed architectures with centralized management and administrationof applications and network performance. For functional, performance,and scalability reasons, a smart grid involving thousands to tens ofthousands of INDE SUBSTATIONS 180 and tens of thousands to millions ofgrid devices may include distributed processing, data management, andprocess communications.

The INDE SUBSTATION 180 may include one or more processors and one ormore memory devices (such as substation non-operational data 181 andsubstation operations data 182). Non-operational data 181 and substationoperations data 182 may be associated with and proximate to thesubstation, such as located in or on the INDE SUBSTATION 180. The INDESUBSTATION 180 may further include components of the smart grid that areresponsible for the observability of the smart grid at a substationlevel. The INDE SUBSTATION 180 components may provide three primaryfunctions: operational data acquisition and storage in the distributedoperational data store; acquisition of non-operational data and storagein the historian; and local analytics processing on a real time (such asa sub-second) basis. Processing may include digital signal processing ofvoltage and current waveforms, detection and classification processing,including event stream processing; and communications of processingresults to local systems and devices as well as to systems at theoperations control center 116. Communication between the INDE SUBSTATION180 and other devices in the grid may be wired, wireless, or acombination of wired and wireless. For example, the transmission of datafrom the INDE SUBSTATION 180 to the operations control center 116 may bewired. The INDE SUBSTATION 180 may transmit data, such asoperation/non-operational data or event data, to the operations controlcenter 116. Routing device 190 may route the transmitted data to one ofthe operational/non-operational data bus 146 or the event bus 147.

Demand response optimization for distribution loss management may alsobe performed here. This architecture is in accordance with thedistributed application architecture principle previously discussed.

For example, connectivity data may be duplicated at the substation 170and at the operations control center 116, thereby allowing a substation170 to operate independently even if the data communication network tothe operations control center 116 is not functional. With thisinformation (connectivity) stored locally, substation analytics may beperformed locally even if the communication link to the operationscontrol center is inoperative.

Similarly, operational data may be duplicated at the operations controlcenter 116 and at the substations 170. Data from the sensors and devicesassociated with a particular substation may be collected and the latestmeasurement may be stored in this data store at the substation. The datastructures of the operational data store may be the same and hencedatabase links may be used to provide seamless access to data thatresides on the substations thru the instance of the operational datastore at the control center. This provides a number of advantagesincluding alleviating data replication and enabling substation dataanalytics, which is more time sensitive, to occur locally and withoutreliance on communication availability beyond the substation. Dataanalytics at the operations control center level 116 may be less timesensitive (as the operations control center 116 may typically examinehistorical data to discern patterns that are more predictive, ratherthan reactive) and may be able to work around network issues if any.

Finally, historical data may be stored locally at the substation and acopy of the data may be stored at the control center. Or, database linksmay be configured on the repository instance at the operations controlcenter 116, providing the operations control center access to the dataat the individual substations. Substation analytics may be performedlocally at the substation 170 using the local data store. Specifically,using the additional intelligence and storage capability at thesubstation enables the substation to analyze itself and to correctitself without input from a central authority. Alternatively,historical/collective analytics may also be performed at the operationscontrol center level 116 by accessing data at the local substationinstances using the database links.

INDE DEVICE

The INDE DEVICE 188 group may comprise any variety of devices within thesmart grid, including various sensors within the smart grid, such asvarious distribution grid devices 189 (e.g., line sensors on the powerlines), meters 163 at the customer premises, etc. The INDE DEVICE 188group may comprise a device added to the grid with particularfunctionality (such as a smart Remote Terminal Unit (RTU) that includesdedicated programming), or may comprise an existing device within thegrid with added functionality (such as an existing open architecturepole top RTU that is already in place in the grid that may be programmedto create a smart line sensor or smart grid device). The INDE DEVICE 188may further include one or more processors and one or more memorydevices.

Existing grid devices may not be open from the software standpoint, andmay not be capable of supporting much in the way of modern networking orsoftware services. The existing grid devices may have been designed toacquire and store data for occasional offload to some other device suchas a laptop computer, or to transfer batch files via PSTN line to aremote host on demand. These devices may not be designed for operationin a real time digital network environment. In these cases, the griddevice data may be obtained at the substation level 170, or at theoperations control center level 116, depending on how the existingcommunications network has been designed. In the case of metersnetworks, it will normally be the case that data is obtained from themeter data collection engine, since meter networks are usually closedand the meters may not be addressed directly. As these networks evolve,meters and other grid devices may be individually addressable, so thatdata may be transported directly to where it is needed, which may notnecessarily be the operations control center 116, but may be anywhere onthe grid.

Devices such as faulted circuit indicators may be married with wirelessnetwork interface cards, for connection over modest speed (such as 100kbps) wireless networks. These devices may report status by exceptionand carry out fixed pre-programmed functions. The intelligence of manygrid devices may be increased by using local smart RTUs. Instead ofhaving poletop RTUs that are designed as fixed function, closedarchitecture devices, RTUs may be used as open architecture devices thatcan be programmed by third parties and that may serve as an INDE DEVICE188 in the INDE Reference Architecture. Also, meters at customers'premises may be used as sensors. For example, meters may measureconsumption (such as how much energy is consumed for purposes ofbilling) and may measure voltage (for use in volt/VAr optimization).

FIGS. 5A-B illustrate an example architecture for INDE DEVICE 188 group.Table 3 describes the certain INDE DEVICE 188 elements. The smart griddevice may include an embedded processor, so the processing elements areless like SOA services and more like real time program library routines,since the DEVICE group is implemented on a dedicated real time DSP ormicroprocessor.

TABLE 3 INDE DEVICE Elements INDE DEVICE ELEMENTS Description Ringbuffers 502 Local circular buffer storage for digital waveforms sampledfrom analog transducers (voltage and current waveforms for example)which may be used hold the data for waveforms at different time periodsso that if an event is detected, the waveform data leading up to theevent may also be stored Device status Buffer storage for externaldevice state and state buffers 504 transition data Three phase Computesa running estimate of the power frequency frequency from all threephases; used for tracker frequency correction to other data as well asin 506 grid stability and power quality measures (especially as relatesto DG) Fourier transform Conversion of time domain waveforms to block508 frequency domain to enable frequency domain analytics Time domainProcessing of the signals in the time domain; signal analyticsextraction of transient and envelop behavior 510 measures FrequencyProcessing of the signals in the frequency domain; domain signalextraction of RMS and power parameters analytics 512 Secondary signalCalculation and compensation of phasors; analytics 514 calculation ofselected error/fault measures Tertiary signal Calculation ofsynchrophasors based on GPS analytics 516 timing and a system referenceangle Event analysis and Processing of all analytics for event detectionand triggers 518 triggering of file capture. Different types of INDEDEVICES may include different event analytical capability. For example,a line sensor may examine ITIC events, examining spikes in the waveform.If a spike occurs (or a series of spikes occur), the line sensor, withthe event analytical capability, may determine that an “event” hasoccurred and also may provide a recommendation as to the cause of theevent. The event analytical capability may be rule-based, with differentrules being used for different INDE DEVICES and different applications.File storage - Capture of data from the ring buffers based on capture/event triggers formatting/transmission 520 Waveform streaming Supportfor streaming of waveforms to a remote service 522 display clientCommunications stack Support for network communications and remoteprogram load GPS Timing 524 Provides high resolution timing tocoordinate applications and synchronize data collection across a widegeographic area. The generated data may include a GPS data frame timestamp 526. Status analytics 528 Capture of data for status messages

FIG. 1A further depicts customer premises 179, which may include one ormore Smart Meters 163, an in-home display 165, one or more sensors 166,and one or more controls 167. In practice, sensors 166 may register dataat one or more devices at the customer premises 179. For example, asensor 166 may register data at various major appliances within thecustomer premises 179, such as the furnace, hot water heater, airconditioner, etc. The data from the one or more sensors 166 may be sentto the Smart Meter 163, which may package the data for transmission tothe operations control center 116 via utility communication network 160.The in-home display 165 may provide the customer at the customerpremises with an output device to view, in real-time, data collectedfrom Smart Meter 163 and the one or more sensors 166. In addition, aninput device (such as a keyboard) may be associated with in-home display165 so that the customer may communicate with the operations controlcenter 116. In one embodiment, the in-home display 165 may comprise acomputer resident at the customer premises.

The customer premises 165 may further include controls 167 that maycontrol one or more devices at the customer premises 179. Variousappliances at the customer premises 179 may be controlled, such as theheater, air conditioner, etc., depending on commands from the operationscontrol center 116.

As depicted in FIG. 1A, the customer premises 169 may communicate in avariety of ways, such as via the Internet 168, the public-switchedtelephone network (PSTN) 169, or via a dedicated line (such as viacollector 164). Via any of the listed communication channels, the datafrom one or more customer premises 179 may be sent. As shown in FIG. 1,one or more customer premises 179 may comprise a Smart Meter Network 178(comprising a plurality of smart meters 163), sending data to acollector 164 for transmission to the operations control center 116 viathe utility management network 160. Further, various sources ofdistributed energy generation/storage 162 (such as solar panels, etc.)may send data to a monitor control 161 for communication with theoperations control center 116 via the utility management network 160.

As discussed above, the devices in the power grid outside of theoperations control center 116 may include processing and/or storagecapability. The devices may include the INDE SUBSTATION 180 and the INDEDEVICE 188. In addition to the individual devices in the power gridincluding additional intelligence, the individual devices maycommunicate with other devices in the power grid, in order to exchangeinformation (include sensor data and/or analytical data (such as eventdata)) in order to analyze the state of the power grid (such asdetermining faults) and in order to change the state of the power grid(such as correcting for the faults). Specifically, the individualdevices may use the following: (1) intelligence (such as processingcapability); (2) storage (such as the distributed storage discussedabove); and (3) communication (such as the use of the one or more busesdiscussed above). In this way, the individual devices in the power gridmay communicate and cooperate with one another without oversight fromthe operations control center 116.

For example, the INDE architecture disclosed above may include a devicethat senses at least one parameter on the feeder circuit. The device mayfurther include a processor that monitors the sensed parameter on thefeeder circuit and that analyzes the sensed parameter to determine thestate of the feeder circuit. For example, the analysis of the senseparameter may comprise a comparison of the sensed parameter with apredetermined threshold and/or may comprise a trend analysis. One suchsensed parameter may include sensing the waveforms and one such analysismay comprise determining whether the sensed waveforms indicate a faulton the feeder circuit. The device may further communicate with one ormore substations. For example, a particular substation may supply powerto a particular feeder circuit. The device may sense the state of theparticular feeder circuit, and determine whether there is a fault on theparticular feeder circuit. The device may communicate with thesubstation. The substation may analyze the fault determined by thedevice and may take corrective action depending on the fault (such asreducing the power supplied to the feeder circuit). In the example ofthe device sending data indicating a fault (based on analysis ofwaveforms), the substation may alter the power supplied to the feedercircuit without input from the operations control center 116. Or, thesubstation may combine the data indicating the fault with informationfrom other sensors to further refine the analysis of the fault. Thesubstation may further communicate with the operations control center116, such as the outage intelligence application (such as discussedFIGS. 13A-B) and/or the fault intelligence application (such asdiscussed in FIGS. 14A-C). Thus, the operations control center 116 maydetermine the fault and may determine the extent of the outage (such asthe number of homes affected by the fault). In this way, the devicesensing the state of the feeder circuit may cooperatively work with thesubstation in order to correct a potential fault with or withoutrequiring the operations control center 116 to intervene.

As another example, a line sensor, which includes additionalintelligence using processing and/or memory capability, may produce gridstate data in a portion of the grid (such as a feeder circuit). The gridstate data may be shared with the demand response management system 155at the operations control center 116. The demand response managementsystem 155 may control one or more devices at customer sites on thefeeder circuit in response to the grid state data from the line sensor.In particular, the demand response management system 155 may command theenergy management system 156 and/or the distribution management system157 to reduce load on the feeder circuit by turning off appliances atthe customer sites that receive power from the feeder circuit inresponse to line sensor indicating an outage on the feeder circuit. Inthis way, the line sensor in combination with the demand responsemanagement system 155 may shift automatically load from a faulty feedercircuit and then isolate the fault.

As still another example, one or more relays in the power grid may havea microprocessor associated with it. These relays may communicate withother devices and/or databases resident in the power grid in order todetermine a fault and/or control the power grid.

INDS Concept and Architecture Outsourced Smart Grid Data/AnalyticsServices Model

One application for the smart grid architecture allows the utility tosubscribe to grid data management and analytics services whilemaintaining traditional control systems and related operational systemsin-house. In this model, the utility may install and own grid sensorsand devices (as described above), and may either own and operate thegrid data transport communication system, or may outsource it. The griddata may flow from the utility to a remote Intelligent Network DataServices (INDS) hosting site, where the data may be managed, stored, andanalyzed. The utility may then subscribe to data and analytics servicesunder an appropriate services financial model. The utility may avoid theinitial capital expenditure investment and the ongoing costs ofmanagement, support, and upgrade of the smart grid data/analyticsinfrastructure, in exchange for fees. The INDE Reference Architecture,described above, lends itself to the outsourcing arrangement describedherein.

INDS Architecture for Smart Grid Services

In order to implement the INDS services model, the INDE ReferenceArchitecture may be partitioned into a group of elements that may behosted remotely, and those that may remain at the utility. FIGS. 6A-Cillustrate how the utility architecture may look once the INDE CORE 120has been made remote. A server may be included as part of the INDE CORE120 that may act as the interface to the remote systems. To the utilitysystems, this may appear as a virtual INDE CORE 602.

As the overall block diagram 600 in FIGS. 6A-C show, the INDE SUBSTATION180 and INDE DEVICE 188 groups are unchanged from that depicted in FIGS.1A-C. The multiple bus structure may also still be employed at theutility as well.

The INDE CORE 120 may be remotely hosted, as the block diagram 700 inFIG. 7 illustrates. At the hosting site, INDE COREs 120 may be installedas needed to support utility INDS subscribers (shown as North AmericanINDS Hosting Center 702). Each CORE 120 may be a modular system, so thatadding a new subscriber is a routine operation. A party separate fromthe electric utility may manage and support the software for one, some,or all of the INDE COREs 120, as well as the applications that aredownloaded from the INDS hosting site to each utility's INDE SUBSTATION180 and INDE DEVICES 188.

In order to facilitate communications, high bandwidth low latencycommunications services, such as via network 704 (e.g., a MPLS or otherWAN), may be use that can reach the subscriber utility operationscenters, as well as the INDS hosting sites. As shown in FIG. 7, variousareas may be served, such as California, Florida, and Ohio. Thismodularity of the operations not only allows for efficient management ofvarious different grids. It also allows for better inter-gridmanagement. There are instances where a failure in one grid may affectoperations in a neighboring grid. For example, a failure in the Ohiogrid may have a cascade effect on operations in a neighboring grid, suchas the mid-Atlantic grid. Using the modular structure as illustrated inFIG. 7 allows for management of the individual grids and management ofinter-grid operations. Specifically, an overall INDS system (whichincludes a processor and a memory) may manage the interaction betweenthe various INDE COREs 120. This may reduce the possibility of acatastrophic failure that cascades from one grid to another. Forexample, a failure in the Ohio grid may cascade to a neighboring grid,such as the mid-Atlantic grid. The INDE CORE 120 dedicated to managingthe Ohio grid may attempt to correct for the failure in the Ohio grid.And, the overall INDS system may attempt to reduce the possibility of acascade failure occurring in neighboring grids.

Specific Examples of Functionality in INDE CORE

As shown in FIGS. 1, 6, and 7, various functionalities (represented byblocks) are included in the INDE CORE 120, two of which depicted aremeter data management services (MDMS) 121 and metering analytics andservices 122. Because of the modularity of the architecture, variousfunctionality, such as MDMS 121 and metering analytics and services 122,may be incorporated.

Observability Processes

As discussed above, one functionality of the application services mayinclude observability processes. The observability processes may allowthe utility to “observe” the grid. These processes may be responsiblefor interpreting the raw data received from all the sensors and deviceson the grid and turning them into actionable information. FIG. 8includes a listing of some examples of the observability processes.

FIGS. 9A-B illustrate a flow diagram 900 of the Grid State Measurement &Operations Processes. As shown, the Data Scanner may request meter data,as shown at block 902. The request may be sent to one or more griddevices, substation computers, and line sensor RTUs. In response to therequest, the devices may collect operations data, as shown at blocks904, 908, 912, and may send data (such as one, some or all of theoperational data, such as Voltage, Current, Real Power, and ReactivePower data), as shown at blocks 906, 910, 914. The data scanner maycollect the operational data, as shown at block 926, and may send thedata to the operational data store, as shown at block 928. Theoperational data store may store the operational data, as shown at block938. The operational data store may further send a snapshot of the datato the historian, as shown at block 940, and the historian may store thesnapshot of the data, as shown at block 942.

The meter state application may send a request for meter data to theMeter DCE, as shown in block 924, which in turn sends a request to oneor more meters to collect meter data, as shown at block 920. In responseto the request, the one or more meters collects meter data, as shown atblock 916, and sends the voltage data to the Meter DCE, as shown atblock 918. The Meter DCE may collect the voltage data, as shown at block922, and send the data to the requestor of the data, as shown at block928. The meter state application may receive the meter data, as shown atblock 930, and determine whether it is for a single value process or avoltage profile grid state, as shown at block 932. If it is for thesingle value process, the meter data is send to the requesting process,as shown at block 936. If the meter data is for storage to determine thegrid state at a future time, the meter data is stored in the operationaldata store, as shown at block 938. The operational data store furthersends a snapshot of the data to the historian, as shown at block 940,and the historian stores the snapshot of the data, as shown at block942.

FIGS. 9A-B further illustrate actions relating to demand response (DR).Demand response refers to dynamic demand mechanisms to manage customerconsumption of electricity in response to supply conditions, forexample, having electricity customers reduce their consumption atcritical times or in response to market prices. This may involveactually curtailing power used or by starting on site generation whichmay or may not be connected in parallel with the grid. This may bedifferent from energy efficiency, which means using less power toperform the same tasks, on a continuous basis or whenever that task isperformed. In demand response, customers, using one or more controlsystems, may shed loads in response to a request by a utility or marketprice conditions. Services (lights, machines, air conditioning) may bereduced according to a preplanned load prioritization scheme during thecritical timeframes. An alternative to load shedding is on-sitegeneration of electricity to supplement the power grid. Under conditionsof tight electricity supply, demand response may significantly reducethe peak price and, in general, electricity price volatility.

Demand response may generally be used to refer to mechanisms used toencourage consumers to reduce demand, thereby reducing the peak demandfor electricity. Since electrical systems are generally sized tocorrespond to peak demand (plus margin for error and unforeseen events),lowering peak demand may reduce overall plant and capital costrequirements. Depending on the configuration of generation capacity,however, demand response may also be used to increase demand (load) attimes of high production and low demand. Some systems may therebyencourage energy storage to arbitrage between periods of low and highdemand (or low and high prices). As the proportion of intermittent powersources such as wind power in a system grows, demand response may becomeincreasingly important to effective management of the electric grid.

The DR state application may request the DR available capacity, as shownat block 954. The DR management system may then request availablecapacity from one or more DR home devices, as shown at block 948. Theone or more home devices may collect available DR capacity in responseto the request, as shown at block 944, and send the DR capacity andresponse data to the DR management system, as shown at block 946. The DRmanagement system may collect the DR capacity and response data, asshown at block 950, and send the DR capacity and response data to the DRstate application, as shown at block 952. The DR state application mayreceive the DR capacity and response data, as shown at block 956, andsend the capacity and response data to the operational data store, asshown at block 958. The operational data store may store the DR capacityand response data, as shown at block 938. The operational data store mayfurther send a snapshot of the data to the historian, as shown at block940, and the historian may store the snapshot of the data, as shown atblock 942.

The substation computer may request application data from the substationapplication, as shown at block 974. In response, the substationapplication may request application from the substation device, as shownat block 964. The substation device may collect the application data, asshown at block 960, and send the application data to the substationdevice (which may include one, some or all of Voltage, Current, RealPower, and Reactive Power data), as shown at block 962. The substationapplication may collect the application data, as shown at block 966, andsend the application data to the requestor (which may be the substationcomputer), as shown at block 968. The substation computer may receivethe application data, as shown at block 970, and send the applicationdata to the operational data store, as shown at block 972.

The grid state measurement and operational data process may comprisederiving the grid state and grid topology at a given point in time, aswell as providing this information to other system and data stores. Thesub-processes may include: (1) measuring and capturing grid stateinformation (this relates to the operational data pertaining to the gridthat was discussed previously); (2) sending grid state information toother analytics applications (this enables other applications, such asanalytical applications, access to the grid state data); (3) persistinggrid state snapshot to connectivity/operational data store (this allowsfor updating the grid state information to the connectivity/operationaldata store in the appropriate format as well as forwarding thisinformation to the historian for persistence so that a point in timegrid topology may be derived at a later point in time); (4) derivinggrid topology at a point in time based on default connectivity andcurrent grid state (this provides the grid topology at a given point intime by applying the point in time snapshot of the grid state in thehistorian to the base connectivity in the connectivity data store, asdiscussed in more detail below); and (5) providing grid topologyinformation to applications upon request.

With regard to sub-process (4), the grid topology may be derived for apredetermined time, such as in real-time, 30 seconds ago, 1 month ago,etc. In order to recreate the grid topology, multiple databases may beused, and a program to access the data in the multiple databases torecreate the grid topology. One database may comprise a relationaldatabase that stores the base connectivity data (the “connectivitydatabase”). The connectivity database may hold the grid topologyinformation as built in order to determine the baseline connectivitymodel. Asset and topology information may be updated into this databaseon a periodic basis, depending on upgrades to the power grid, such asthe addition or modification of circuits in the power grid (e.g.,additional feeder circuits that are added to the power grid). Theconnectivity database may be considered “static” in that it does notchange. The connectivity database may change if there are changes to thestructure of the power grid. For example, if there is a modification tothe feeder circuits, such as an addition of a feeder circuit, theconnectivity database may change.

One example of the structure 1800 of the connectivity database may bederived from the hierarchical model depicted in FIGS. 18A-D. Thestructure 1800 is divided into four sections, with FIG. 18A being theupper-left section, FIG. 18B being the upper-right section, FIG. 18Cbeing the bottom-left section, and FIG. 18D being the bottom-rightsection. Specifically, FIGS. 18A-D are an example of an entityrelationship diagram, which is an abstract method to represent thebaseline connectivity database. The hierarchical model in FIGS. 18A-Dmay hold the meta-data that describes the power grid and may describethe various components of a grid and the relationship between thecomponents.

A second database may be used to store the “dynamic” data. The seconddatabase may comprise a non-relational database. One example of anon-relational database may comprise a historian database, which storesthe time series non-operational data as well as the historicaloperational data. The historian database may stores a series of “flat”records such as: (1) time stamp; (2) device ID; (3) a data value; and(4) a device status. Furthermore, the stored data may be compressed.Because of this, the operation/non-operational data in the power gridmay be stored easily, and may be manageable even though a considerableamount of data may be available. For example, data on the order of 5Terabytes may be online at any given time for use in order to recreatethe grid topology. Because the data is stored in the simple flat record(such as no organizational approach), it allows efficiency in storingdata. As discussed in more detail below, the data may be accessed by aspecific tag, such as the time stamp.

Various analytics for the grid may wish to receive, as input, the gridtopology at a particular point in time. For example, analytics relatingto power quality, reliability, asset health, etc. may use the gridtopology as input. In order to determine the grid topology, the baselineconnectivity model, as defined by the data in the connectivity database,may be accessed. For example, if the topology of a particular feedercircuit is desired, the baseline connectivity model may define thevarious switches in the particular feeder circuit in the power grid.After which, the historian database may be accessed (based on theparticular time) in order to determine the values of the switches in theparticular feeder circuit. Then, a program may combine the data from thebaseline connectivity model and the historian database in order togenerate a representation of the particular feeder circuit at theparticular time.

A more complicated example to determine the grid topology may includemultiple feeder circuits (e.g., feeder circuit A and feeder circuit B)that have an inter-tie switch and sectionalizing switches. Depending onthe switch states of certain switches (such as the inter-tie switchand/or the sectionalizing switches), sections of the feeder circuits maybelong to feeder circuit A or feeder circuit B. The program thatdetermines the grid topology may access the data from both the baselineconnectivity model and the historian database in order to determine theconnectivity at a particular time (e.g., which circuits belong to feedercircuit A or feeder circuit B).

FIG. 10 illustrates a flow diagram 1000 of the Non-Operational Dataprocesses. The non-operational extract application may requestnon-operational data, as shown at block 1002. In response, the datascanner may gather non-operational data, as shown at block 1004, whereby various devices in the power grid, such as grid devices, substationcomputers, and line sensor RTUs, may collect non-operational data, asshown at blocks 1006, 1008, 1110. As discussed above, non-operationaldata may include temperature, power quality, etc. The various devices inthe power grid, such as grid devices, substation computers, and linesensor RTUs, may send the non-operational data to the data scanner, asshown at blocks 1012, 1014, 1116. The data scanner may collect thenon-operational data, as shown at block 1018, and send thenon-operational data to the non-operational extract application, asshown at block 1020. The non-operational extract application may collectthe non-operational data, as shown at block 1022, and send the collectednon-operational data to the historian, as shown at block 1024. Thehistorian may receive the non-operational data, as shown at block 1026,store the non-operational data, as shown at block 1028, and send thenon-operational data to one or more analytics applications, as shown atblock 1030.

FIG. 11 illustrates a flow diagram 1100 of the Event Managementprocesses. Data may be generated from various devices based on variousevents in the power grid and sent via the event bus 147. For example,the meter data collection engine may send power outage/restorationnotification information to the event bus, as shown at block 1102. Theline sensors RTUs generate a fault message, and may send the faultmessage to the event bus, as shown at block 1104. The substation mayanalytics may generate a fault and/or outage message, and may send thefault and/or outage message to the event bus, as shown at block 1106.The historian may send signal behavior to the event bus, as shown atblock 1108. And, various processes may send data via the event bus 147.For example, the fault intelligence process, discussed in more detail inFIGS. 14A-C, may send a fault analysis event via the event bus, as shownat block 1110. The outage intelligence process, discussed in more detailin FIGS. 13A-B, may send an outage event via the event bus, as shown atblock 1112. The event bus may collect the various events, as shown atblock 1114. And, the Complex Event Processing (CEP) services may processthe events sent via the event bus, as shown at block 1120. The CEPservices may process queries against multiple concurrent high speed realtime event message streams. After processing by the CEP services, theevent data may be sent via the event bus, as shown at block 1118. Andthe historian may receive via the event bus one or more event logs forstorage, as shown at block 1116. Also, the event data may be received byone or more applications, such as the outage management system (OMS),outage intelligence, fault analytics, etc., as shown at block 1122. Inthis way, the event bus may send the event data to an application,thereby avoiding the “silo” problem of not making the data available toother devices or other applications.

FIGS. 12A-C illustrate a flow diagram 1200 of the Demand Response (DR)Signaling processes. DR may be requested by the distribution operationapplication, as shown at block 1244. In response, the gridstate/connectivity may collect DR availability data, as shown at block1202, and may send the data, as shown at block 1204. The distributionoperation application may distribute the DR availability optimization,as show at block 1246, via the event bus (block 1254), to one or more DRManagement Systems. The DR Management System may send DR information andsignals to one or more customer premises, as shown at block 1272. Theone or more customer premises may receive the DR signals, as shown atblock 1266, and send the DR response, as shown at block 1268. The DRManagement may receive the DR response, as shown at block 1274, and sendDR responses to one, some or all of the operations data bus 146, thebilling database, and the marketing database, as shown at block 1276.The billing database and the marketing database may receive theresponses, as shown at blocks 1284, 1288. The operations data bus 146may also receive the responses, as shown at block 1226, and send the DRresponses and available capacity to the DR data collection, as shown atblock 1228. The DR data collection may process the DR responses andavailable capacity, as shown at block 1291, and send the data to theoperations data bus, as shown at block 1294. The operations data bus mayreceive the DR availability and response, as shown at block 1230, andsend it to the grid state/connectivity. The grid state/connectivity mayreceive the data, as shown at block 1208. The received data may be usedto determine the grid state data, which may be sent (block 1206) via theoperations data bus (block 1220). The distribution operation applicationmay receive the grid state data (as an event message for DRoptimization), as shown at block 1248. Using the grid state data and theDR availability and response, the distribution operation application mayrun distribution optimization to generate distribution data, as shown atblock 1250. The distribution data may be retrieved by the operationsdata bus, as shown at block 1222, and may be sent to the connectivityextract application, as shown at block 1240. The operational data busmay send data (block 1224) to the distribution operation application,which in turn may send one or more DR signals to one or more DRManagement Systems (block 1252). The event bus may collect signals foreach of the one or more DR Management Systems (block 1260) and send theDR signals to each of the DR Management Systems (block 1262). The DRManagement System may then process the DR signals as discussed above.

The communication operation historian may send data to the event bus, asshown at block 1214. The communication operation historian may also sendgeneration portfolio data, as shown at block 1212. Or, an assetmanagement device, such as a Ventyx®, may request virtual power plant(VPP) information, as shown at block 1232. The operations data bus maycollect the VPP data, as shown at block 1216, and send the data to theasset management device, as shown at block 1218. The asset managementdevice may collect the VPP data, as shown at block 1234, run systemoptimization, as shown at block 1236, and send VPP signals to the eventbus, as shown at block 1238. The event bus may receive the VPP signals,as shown at block 1256, and send the VPP signals to the distributionoperation application, as shown at block 1258. The distributionoperation application may then receive and process the event messages,as discussed above.

The connection extract application may extract new customer data, asshown at block 1278, to be sent to the Marketing Database, as shown atblock 1290. The new customer data may be sent to the gridstate/connectivity, as shown at block 1280, so that the grid stateconnectivity may receive new DR connectivity data, as shown at block1210.

The operator may send one or more override signals when applicable, asshown at block 1242. The override signals may be sent to thedistribution operation application. The override signal may be sent tothe energy management system, as shown at block 1264, the billingdatabase, as shown at block 1282, and/or the marketing database, asshown at block 1286.

FIGS. 13A-B illustrate a flow diagram 1300 of the Outage Intelligenceprocesses. Various devices and applications may send power outagenotification, as shown at blocks 1302, 1306, 1310, 1314, 1318. Theoutage events may be collected by the event bus, as shown at block 1324,which may send the outage events to the complex event processing (CEP),as shown at block 1326. Further, various devices and applications maysend power restoration status, as shown at block 1304, 1308, 1312, 1316,1320. The CEP may receive outage and restoration status messages (block1330), process the events (block 1332), and send event data (block1334). The outage intelligence application may receive the event data(block 1335) and request grid state and connectivity data (block 1338).The operational data bus may receive the request for grid state andconnectivity data (block 1344) and forward it to one or both of theoperational data store and the historian. In response, the operationaldata store and the historian may send the grid state and connectivitydata (blocks 1352, 1354) via the operational data bus (block 1346) tothe outage intelligence application (block 1340). It is determinedwhether the grid state and connectivity data indicate whether this was amomentary, as shown at block 1342. If so, the momentaries are sent viathe operational data bus (block 1348) to the momentaries database forstorage (block 1350). If not, an outage case is created (block 1328) andthe outage case data is stored and processed by the outage managementsystem (block 1322).

The outage intelligence processes may: detect outages; classify & logmomentaries; determine outage extent; determine outage root cause(s);track outage restoration; raise outage events; and update systemperformance indices.

FIGS. 14A-C illustrate a flow diagram 1400 of the Fault Intelligenceprocesses. The complex event processing may request data from one ormore devices, as shown at block 1416. For example, the grid state andconnectivity in response to the request may send grid state andconnectivity data to the complex event processing, as shown at block1404. Similarly, the historian in response to the request may send realtime switch state to the complex event processing, as shown at block1410. And, the complex event processing may receive the grid state,connectivity data, and the switch state, as shown at block 1418. Thesubstation analytics may request fault data, as shown at block 1428.Fault data may be sent by a variety of devices, such as line sensorRTUs, and substation computers, as shown at blocks 1422, 1424. Thevarious fault data, grid state, connectivity data, and switch state maybe sent to the substation analytics for event detection andcharacterization, as shown at block 1430. The event bus may also receiveevent messages (block 1434) and send the event messages to thesubstation analytics (block 1436). The substation analytics maydetermine the type of event, as shown at block 1432. For protection andcontrol modification events, the substation computers may receive afault event message, as shown at block 1426. For all other types ofevents, the event may be received by the event bus (block 1438) and sentto the complex event processing (block 1440). The complex eventprocessing may receive the event data (block 1420) for furtherprocessing. Similarly, the grid state and connectivity may send gridstate data to the complex event processing, as shown at block 1406. And,the Common Information Model (CIM) warehouse may send meta data to thecomplex event processing, as shown at block 1414.

The complex event processing may send a fault event message, as shown atblock 1420. The event bus may receive the message (block 1442) and sendthe event message to the fault intelligence application (block 1444).The fault intelligence application may receive the event data (block1432) and request grid state, connectivity data, and switch state, asshown at block 1456. In response to the request, the grid state andconnectivity send grid state and connectivity data (block 1408), and thehistorian send switch state data (block 1412). The fault intelligencereceives the data (block 1458), analyzes the data, and sends event data(block 1460). The event data may be received by the event bus (block1446) and sent to the fault log file (block 1448). The fault log filemay log the event data (block 1402). The event data may also be receivedby the operational data bus (block 1462) and send to one or moreapplications (block 1464). For example, the outage intelligenceapplication may receive the event data (block 1466), discussed abovewith respect to FIGS. 13A-B. The work management system may also receivethe event data in the form of a work order, as shown at block 1468. And,other requesting applications may receive the event data, as shown atblock 1470.

The fault intelligent processes may be responsible for interpreting thegrid data to derive information about current and potential faultswithin the grid. Specifically, faults may be detected using the faultintelligent processes. A fault is typically a short circuit caused whenutility equipment fails or alternate path for current flow is created,for example, a downed power line. This processes may be used to detecttypical faults (typically handled by the conventional fault detectionand protection equipment—relays, fuses, etc) as well as high impedancefaults within the grid that are not easily detectable using faultcurrents.

The fault intelligence process may also classify and categorize faults.This allows for faults to be classified and categorized. Currently, nostandard exists for a systematic organization and classification forfaults. A de-facto standard may be established for the same andimplemented. The fault intelligence process may further characterizefaults.

The fault intelligence may also determine fault location. Fault locationin the distribution system may be a difficult task due to its highcomplexity and difficulty caused by unique characteristics of thedistribution system such as unbalanced loading, three-, two-, andsingle-phase laterals, lack of sensors/measurements, different types offaults, different causes of short circuits, varying loading conditions,long feeders with multiple laterals and network configurations that arenot documented. This process enables the use a number of techniques toisolate the location of the fault with as much accuracy as thetechnology allows.

The fault intelligence may further raise fault events. Specifically,this process may create and publish fault events to the events bus oncea fault has been detected, classified, categorized, characterized andisolated. This process may also be responsible for collecting,filtering, collating and de-duplicating faults so that an individualfault event is raised rather than a deluge based on the raw events thatare typical during a failure. Finally, the fault intelligence may logfault events to the event log database.

FIGS. 15A-B illustrate a flow diagram 1500 of the Meta-data Managementprocesses. Meta-data management processes may include: point listmanagement; and communication connectivity & protocol management; andelement naming & translation; sensor calibration factor management; andreal time grid topology data management. The base connectivity extractapplication may request base connectivity data, as shown at block 1502.The Geographic Information Systems (GIS) may receive the request (block1510) and send data to the base connectivity extract application (block1512). The base connectivity extract application may receive the data(block 1504), extract, transform and load data (block 1506) and sendbase connectivity data to the connectivity data mart (block 1508). Theconnectivity data mart may thereafter receive the data, as shown atblock 1514.

The connectivity data mart may comprise a custom data store thatcontains the electrical connectivity information of the components ofthe grid. As shown in FIGS. 15A-B, this information may be derivedtypically from the Geographic Information System (GIS) of the utility,which holds the as built geographical location of the components thatmake up the grid. The data in this data store describes the hierarchicalinformation about all the components of the grid (substation, feeder,section, segment, branch, t-section, circuit breaker, recloser, switch,etc—basically all the assets). This data store may have the asset andconnectivity information as built.

The meta data extract application may request meta data for grid assets,as shown at block 1516. The meta data database may receive the request(block 1524) and send meta data (block 1526) The meta data extractapplication may receive the meta data (block 1518), extract, transformand load meta data (block 1520), and send the meta data to the CIM datawarehouse (block 1522).

The CIM (Common Information Model) data warehouse may then store thedata, as shown at block 1528. CIM may prescribe utility standard formatsfor representing utility data. The INDE smart grid may facilitate theavailability of information from the smart grid in a utility standardformat. And, the CIM data warehouse may facilitate the conversion ofINDE specific data to one or more formats, such as a prescribed utilitystandard format.

The asset extract application may request information on new assets, asshown at block 1530. The asset registry may receive the request (block1538) and send information on the new assets (block 1540). The assetextract application may receive the information on the new assets (block1532), extract transform and load data (block 1534), and sendinformation on the new assets to the CIM data warehouse (block 1536).

The DR connectivity extract application may request DR connectivitydata, as shown at block 1542. The operational data bus may send the DRconnectivity data request to the marketing database, as shown at block1548. The marketing database may receive the request (block 1554),extract transform, load DR connectivity data (block 1556), and send theDR connectivity data (block 1558). The operational data bus may send theDR connectivity data to the DR connectivity extract application (block1550). The DR connectivity extract application may receive the DRconnectivity data (block 1544), and send the DR connectivity data (block1546) via the operational data bus (block 1552) to the grid state andconnectivity DM, which stores the DR connectivity data (block 1560).

FIG. 16 illustrates a flow diagram 1600 of the Notification Agentprocesses. A notification subscriber may log into a webpage, as shown atblock 1602. The notification subscriber may create/modify/deletescenario watch list parameters, as shown at block 1604. The web page maystore the created/modified/deleted scenario watch list, as shown atblock 1608, and the CIM data warehouse may create a list of data tags,as shown at block 1612. A name translate service may translate the datatags for the historian (block 1614) and send the data tags (block 1616).The web page may send the data tag list (block 1610) via the operationaldata bus, which receives the data tag list (block 1622) and sends it tothe notification agent (block 1624). The notification agent retrievesthe list (block 1626), validates and merges the lists (block 1628), andchecks the historian for notification scenarios (block 1630). Ifexceptions matching the scenarios are found (block 1632), a notificationis sent (block 1634). The event bus receives the notification (block1618) and sends it to the notification subscriber (block 1620). Thenotification subscriber may receive the notification via a preferredmedium, such as text, e-mail, telephone call, etc., as shown at block1606.

FIG. 17 illustrates a flow diagram 1700 of the Collecting Meter Data(AMI) processes. The current collector may request residential meterdata, as shown at block 1706. One or more residential meters may collectresidential meter data in response to the request (block 1702) and sendthe residential meter data (block 1704). The current collector mayreceive the residential meter data (block 1708) and send it to theoperational data bus (block 1710). The meter data collection engine mayrequest commercial and industrial meter data, as shown at block 1722.One or more commercial and industrial meters may collect commercial andindustrial meter data in response to the request (block 1728) and sendthe commercial and industrial meter data (block 1730). The meter datacollection engine may receive the commercial and industrial meter data(block 1724) and send it to the operational data bus (block 1726).

The operational data bus may receive residential, commercial, andindustrial meter data (block 1712) and send the data (block 1714). Thedata may be received by the meter data repository database (block 1716)or may be received by the billing processor (block 1718), which may inturn be sent to one or more systems, such as a CRM (customerrelationship management) system (block 1720).

The observability processes may further include remote asset monitoringprocesses. Monitoring the assets within a power grid may provedifficult. There may be different portions of the power grid, some ofwhich are very expensive. For example, substations may include powertransformers (costing upwards of $1 million), and circuit breakers.Oftentimes, utilities would do little, if anything, in the way ofanalyzing the assets and maximizing the use of the assets. Instead, thefocus of the utility was typically to ensure that the power to theconsumer was maintained. Specifically, the utility was focused onscheduled inspections (which would typically occur at pre-determinedintervals) or “event-driven” maintenance (which would occur if a faultoccurred in a portion of the grid).

Instead of the typical scheduled inspections or “event-driven”maintenance, the remote asset monitoring processes may focus oncondition-based maintenance. Specifically, if one portion (or all) ofthe power grid may be assessed (such as on a periodic or continualbasis), the health of the power grid may be improved.

As discussed above, data may be generated at various portions of thepower grid and transmitted to (or accessible by) a central authority.The data may then be used by the central authority in order to determinethe health of the grid. Apart from analyzing the health of the grid, acentral authority may perform utilization monitoring. Typically,equipment in the power grid is operated using considerable safetymargins. One of the reasons for this is that utility companies areconservative by nature and seek to maintain power to the consumer withina wide margin of error. Another reason for this is that the utilitycompanies monitoring the grid may not be aware of the extent a piece ofequipment in the power grid is being utilized. For example, if a powercompany is transmitting power through a particular feeder circuit, thepower company may not have a means by which to know if the transmittedpower is near the limit of the feeder circuit (for example, the feedercircuit may become excessively heated). Because of this, the utilitycompanies may be underutilizing one or more portions of the power grid.

Utilities also typically spend a considerable amount of money to addcapacity to the power grid since the load on the power grid has beengrowing (i.e., the amount of power consumed has been increasing).Because of the Utilities' ignorance, Utilities will upgrade the powergrid unnecessarily. For example, feeder circuits that are not operatingnear capacity may nonetheless be upgraded by reconductoring (i.e.,bigger wires are laid in the feeder circuits), or additional feedercircuits may be laid. This cost alone is considerable.

The remote asset monitoring processes may monitor various aspects of thepower grid, such as: (1) analyzing current asset health of one or moreportions of the grid; (2) analyzing future asset health of one or moreportions of the grid; and (3) analyzing utilization of one or moreportions of the grid. First, one or more sensors may measure andtransmit to remote asset monitoring processes in order to determine thecurrent health of the particular portion of the grid. For example, asensor on a power transform may provide an indicator of its health bymeasuring the dissolved gases on the transformer. The remote assetmonitoring processes may then use analytic tools to determine if theparticular portion of the grid (such as the power transform is healthyor not healthy). If the particular portion of the grid is not healthy,the particular portion of the grid may be fixed.

Moreover, the remote asset monitoring processes may analyze datagenerated from portions of the grid in order to predict the future assethealth of the portions of the grid. There are things that cause stresson electrical components. The stress factors may not necessarily beconstant and may be intermittent. The sensors may provide an indicatorof the stress on a particular portion of the power grid. The remoteasset monitoring processes may log the stress measurements, as indicatedby the sensor data, and may analyze the stress measurement to predictthe future health of the portion of the power grid. For example, theremote asset monitoring processes may use trend analysis in order topredict when the particular portion of the grid may fail, and mayschedule maintenance in advance of (or concurrently with) the time whenthe particular portion of the grid may fail. In this way, the remoteasset monitoring processes may predict the life of a particular portionof the grid, and thus determine if the life of that portion of the gridis too short (i.e., is that portion of the grid being used up tooquickly).

Further, the remote asset monitoring processes may analyze theutilization of a portion of the power grid in order to manage the powergrid better. For example, the remote asset monitoring processes mayanalyze a feeder circuit to determine what its operating capacity is. Inthis feeder circuit example, the remote asset monitoring processes maydetermine that the feeder circuit is currently being operated at 70%.The remote asset monitoring processes may further recommend that theparticular feeder circuit may be operated at a higher percentage (suchas 90%), while still maintaining acceptable safety margins. The remoteasset monitoring processes may thus enable an effective increase incapacity simply through analyzing the utilization.

Methodology for Determining Specific Technical Architecture

There are various methodologies for determining the specific technicalarchitecture that may use one, some, or all of the elements of the INDEReference Architecture. The methodology may include a plurality ofsteps. First, a baseline step may be performed in generatingdocumentation of the as-is state of the utility, and a readinessassessment for transition to a Smart Grid. Second, a requirementsdefinition step may be performed in generating the definition of theto-be state and the detailed requirements to get to this state.

Third, a solution development step may be performed in generating thedefinition of the solution architecture components that will enable theSmart Grid including the measurement, monitoring and control. For theINDE architecture, this may include the measuring devices, thecommunication network to pass data from the devices to the INDE CORE 120applications, the INDE CORE 120 applications to persist and react to thedata, analytical applications to interpret the data, the dataarchitecture to model the measured and interpreted data, the integrationarchitecture to exchange data and information between INDE and utilitysystems, the technology infrastructure to run the various applicationsand databases and the standards that may be followed to enable anindustry standard portable and efficient solution.

Fourth, a value modeling may be performed in generating the definitionof key performance indicators and success factors for the Smart Grid andthe implementation of the ability to measure and rate the systemperformance against the desired performance factors. The disclosureabove relates to the Architecture development aspect of step 3.

FIGS. 19A-B illustrate an example of a blueprint progress flow graphic.Specifically, FIGS. 19A-B illustrate a process flow of the steps thatmay be undertaken to define the smart grid requirements and the stepsthat may be executed to implement the smart grid. The smart griddevelopment process may begin with a smart grid vision development,which may outline the overall goals of the project, that may lead to thesmart grid roadmapping process. The roadmapping process may lead toblueprinting and to value modeling.

Blueprinting may provide a methodical approach to the definition of thesmart grid in the context of the entire utility enterprise. Blueprintingmay include an overall roadmap, which may lead to a baseline and systemsevaluation (BASE) and to a requirements definition and analyticsselection (RDAS). The RDAS process may create the detailed definition ofthe utility's specific smart grid.

The BASE process may establish the starting point for the utility, interms of systems, networks, devices, and applications to support smartgrid capabilities. The first part of the process is to develop a systemsinventory of the grid, which may include: grid structure (such asgeneration, transmission lines, transmission substations, subtransmission lines, distribution substations, distribution feeders,voltage classes); grid devices (such as switches, reclosers, capacitors,regulators, voltage drop compensators, feeder inter-ties); substationautomation (such as IEDs, substation LANs, instrumentation, stationRTUs/computers); distribution automation (such as capacitor and switchcontrol; fault isolation and load rollover controls; LTC coordinationsystems; DMS; Demand Response Management System); and grid sensors (suchas sensor types, amounts, uses, and counts on distribution grids, ontransmission lines and in substations); etc. Once the inventory iscomplete, an evaluation of the utility against a high level smart gridreadiness model may be created. An as-is dataflow model and a systemsdiagram may also be created.

The architecture configuration (ARC) process may develop a preliminarysmart grid technical architecture for the utility by combining theinformation from the BASE process, requirements and constraints from theRDAS process and the INDE Reference Architecture to produce a technicalarchitecture that meets the specific needs of the utility and that takesadvantage of the appropriate legacy systems and that conforms to theconstraints that exist at the utility. Use of the INDE ReferenceArchitecture may avoid the need to invent a custom architecture andensures that accumulated experience and best practices are applied tothe development of the solution. It may also ensure that the solutioncan make maximum use of reusable smart grid assets.

The sensor network architecture configuration (SNARC) process mayprovide a framework for making the series of decisions that define thearchitecture of a distributed sensor network for smart grid support. Theframework may be structured as a series of decision trees, each orientedto a specific aspect of sensor network architecture. Once the decisionshave been made, a sensor network architecture diagram may be created.

The sensor allocation via T-section recursion (SATSECTR) process mayprovide a framework for determining how many sensors should be placed onthe distribution grid to obtain a given level of observability, subjectto cost constraints. This process may also determine the sensor typesand locations.

The solution element evaluation and components template (SELECT) processmay provide a framework for evaluation of solution component types andprovides a design template for each component class. The template maycontain a reference model for specifications for each of the solutionelements. These templates may then be used to request vendor quotationsand to support vendor/product evaluations.

The upgrade planning for applications and networks (UPLAN) process mayprovide for development of a plan to upgrade of existing utilitysystems, applications, and networks to be ready for integration into asmart grid solution. The risk assessment and management planning (RAMP)process may provide an assessment of risk associated with specificelements of the smart grid solution created in the ARC process. TheUPLAN process may assesses the level or risk for identified riskelements and provides an action plan to reduce the risk before theutility commits to a build-out. The change analysis and managementplanning (CHAMP) process may analyze the process and organizationalchanges that may be needed for the utility to realize the value of thesmart grid investment and may provide a high level management plan tocarry out these changes in a manner synchronized with the smart griddeployment. The CHAMP process may result in a blueprint being generated.

The roadmap in the value modeling process may lead to specifying valuemetrics, which may lead to estimation of cost and benefits. Theestimation may lead to the building of one or more cases, such as a ratecase and business case, which in turn may lead to a case closure. Theoutput of blueprinting and the value modeling may be sent to the utilityfor approval, which may result in utility system upgrades and smart griddeployments and risk reduction activities. After which, the grid may bedesigned, built and tested, and then operated.

Alternative INDE High Level Architecture Description

In one example, the overall INDE architecture may be me applied to anindustry including both mobile and stationary sensors. The INDEarchitecture may be implemented to receive sensor data and respondaccordingly through both distributed and centralized intelligence. FIGS.21 through 28 illustrate examples of the INDE architecture implementedin various vehicle travel industries.

Overall Architecture

Turning to the drawings, wherein like reference numerals refer to likeelements, FIGS. 21A-C illustrate one example of the overall architecturefor INDE. This architecture may serve as a reference model that providesfor end to end collection, transport, storage, and management of networkdata related to a one or more particular industries. It may also provideanalytics and analytics management, as well as integration of theforgoing into processes and systems. Hence, it may be viewed as anenterprise-wide architecture. Certain elements, such as operationalmanagement and aspects of the network itself, are discussed in moredetail below.

The architecture depicted in FIGS. 21A-C may include up to four data andintegration buses: (1) a high speed sensor data bus 2146 (which mayinclude operational and non-operational data); (2) a dedicated eventprocessing bus 2147 (which may include event data); (3) an operationsservice bus 2130 (which may serve to provide information about thenetwork back office applications); and (4) an enterprise service bus forthe back office IT systems (shown in FIGS. 1A-C as the enterpriseintegration environment bus 2114 for serving enterprise IT 2115). Theseparate data buses may be achieved in one or more ways. For example,two or more of the data buses, such as the high speed sensor data bus2146 and the event processing bus 2147, may be different segments in asingle data bus. Specifically, the buses may have a segmented structureor platform. As discussed in more detail below, hardware and/orsoftware, such as one or more switches, may be used to route data ondifferent segments of the data bus.

As another example, two or more of the data buses may be on separatebuses, such as separate physical buses in terms of the hardware neededto transport data on the separate buses. Specifically, each of the busesmay include cabling separate from each other. Further, some or all ofthe separate buses may be of the same type. For example, one or more ofthe buses may comprise a local area network (LAN), such as Ethernet®over unshielded twisted pair cabling and Wi-Fi. As discussed in moredetail below, hardware and/or software, such as a router, may be used toroute data onto one bus among the different physical buses.

As still another example, two or more of the buses may be on differentsegments in a single bus structure and one or more buses may be onseparate physical buses. Specifically, the high speed sensor data bus2146 and the event processing bus 2147 may be different segments in asingle data bus, while the enterprise integration environment bus 2114may be on a physically separate bus.

Though FIGS. 21A-C depict four buses, fewer or greater numbers of busesmay be used to carry the four listed types of data. For example, asingle unsegmented bus may be used to communicate the sensor data andthe event processing data (bringing the total number of buses to three),as discussed below. And, the system may operate without the operationsservice bus 2130 and/or the enterprise integration environment bus 2114.

The IT environment may be SOA-compatible. Service Oriented Architecture(SOA) is a computer systems architectural style for creating and usingbusiness processes, packaged as services, throughout their lifecycle.SOA also defines and provisions the IT infrastructure to allow differentapplications to exchange data and participate in business processes.Although, the use of SOA and the enterprise service bus are optional.

In an example of a generic industry, the figures illustrate differentelements within the overall architecture, such as the following: (1)INDE CORE 2120; and (2) INDE DEVICE 2188. This division of the elementswithin the overall architecture is for illustration purposes. Otherdivision of the elements may be used. And, the division of elements maybe different for different industries. The INDE architecture may be usedto support both distributed and centralized approaches to intelligence,and to provide mechanisms for dealing with scale in largeimplementations.

The INDE Reference Architecture is one example of the technicalarchitecture that may be implemented. For example, it may be an exampleof a meta-architecture, used to provide a starting point for developingany number of specific technical architectures, one for each industrysolution (e.g., different solutions for different industries) or one foreach application within an industry (e.g., a first solution for a firstvehicle travel network and a second solution for a second vehicle travelnetwork), as discussed below. Thus, the specific solution for aparticular industry or a particular application within an industry (suchas an application to a particular utility) may include one, some, or allof the elements in the INDE Reference Architecture. And, the INDEReference Architecture may provide a standardized starting point forsolution development. Discussed below is the methodology for determiningthe specific technical architecture for a particular industry or aparticular application within an industry.

The INDE Reference Architecture may be an enterprise wide architecture.Its purpose may be to provide the framework for end to end management ofdata and analytics, and integration of these into systems and processes.Since advanced network technology affects every aspect of businessprocesses, one should be mindful of the effects not just at the networklevel, operations, and customer premise levels, but also at the backoffice and enterprise levels. Consequently the INDE ReferenceArchitecture can and does reference enterprise level SOA, for example,in order to support the SOA environment for interface purposes. Thisshould not be taken as a requirement that an industry, such as, mustconvert their existing IT environment to SOA before the advanced networkcan be built and used. An enterprise service bus is a useful mechanismfor facilitating IT integration, but it is not required in order toimplement the rest of the solution. The discussion below focuses ondifferent components of the INDE elements for vehicle travel; however,one, some, or all of the components of the INDE elements may be appliedto different industries, such as telecommunication and energyexploration.

INDE Component Groups

As discussed above, the different components in the INDE ReferenceArchitecture may include, for example: (1) INDE CORE 2120; and (2) INDEDEVICE 2188. The following sections discuss these example element groupsof the INDE Reference Architecture and provide descriptions of thecomponents of each group.

INDE CORE

FIG. 22 illustrates the INDE CORE 2120, which is the portion of INDEReference Architecture that may reside in an operations control center,as shown in FIGS. 21A-C. The INDE CORE 2120 may contain a unified dataarchitecture for storage of data and an integration schema for analyticsto operate on that data.

In addition, this data architecture may make use of federationmiddleware 2134 to connect other types of data (such as, for example,sensor data, operational and historical data, log and event files), andconnectivity and meta-data files into a single data architecture thatmay have a single entry point for access by high level applications,including enterprise applications. Real time systems may also access keydata stores via the high speed data bus and several data stores canreceive real time data. Different types of data may be transportedwithin one or more buses in the INDE architecture.

The types of data transported may include operation and non-operationaldata, events, network connectivity data, and network location data. Theoperational and non-operational data may be transported using anoperational/non-operational data bus 2146. Data collection applicationsmay be responsible for sending some or all of the data to theoperational/non-operational data bus 2146. In this way, applicationsthat need this information may be able to get the data by subscribing tothe information or by invoking services that may make this dataavailable.

Events may include messages and/or alarms originating from the variousdevices and sensors that are part of an industry network, as discussedbelow. Events may be directly generated from the devices and sensors onthe as well as generated by the various analytics applications based onthe measurement data from these sensors and devices.

As discussed in more detail below, data may be sent from variouscomponents in the (such as INDE DEVICE 2188). The data may be sent tothe INDE CORE 2120 wirelessly, wired, or a combination of both. The datamay be received by utility communications networks 2160, which may sendthe data to routing device 2189. Routing device 2189 may comprisesoftware and/or hardware for managing routing of data onto a segment ofa bus (when the bus comprises a segmented bus structure) or onto aseparate bus. Routing device may comprise one or more switches or arouter. Routing device 2189 may comprise a networking device whosesoftware and hardware routes and/or forwards the data to one or more ofthe buses. For example, the routing device 2189 may route operationaland non-operational data to the operational/non-operational data bus2146. The routing device 2189 may also route event data to the event bus2147.

The routing device 2189 may determine how to route the data based on oneor more methods. For example, the routing device 2189 may examine one ormore headers in the transmitted data to determine whether to route thedata to the segment for the operational/non-operational data bus 2146 orto the segment for the event bus 2147. Specifically, one or more headersin the data may indicate whether the data is operation/non-operationaldata (so that the routing device 2189 routes the data to theoperational/non-operational data bus 2146) or whether the data is eventdata (so that the routing device 2189 routes the event bus 2147).Alternatively, the routing device 2189 may examine the payload of thedata to determine the type of data (e.g., the routing device 2189 mayexamine the format of the data to determine if the data isoperational/non-operational data or event data).

One of the stores, such as the operational data warehouse 2137 thatstores the operational data, may be implemented as true distributeddatabase. Another of the stores, the historian (identified as historicaldata 2136 in FIGS. 21 and 22), may be implemented as a distributeddatabase. Further, events may be stored directly into any of severaldata stores via the complex event processing bus. Specifically, theevents may be stored in event logs 2135, which may be a repository forall the events that have published to the event bus 2147. The event logmay store one, some, or all of the following: event id; event type;event source; event priority; and event generation time. The event bus2147 need not store the events long term, providing the persistence forall the events.

The storage of the data may be such that the data may be as close to thesource as possible or practicable. In one implementation, this mayinclude, for example, the substation data being stored at the INDEDEVICE 2188. But this data may also be required at the operationscontrol center level 2116 to make different types of decisions thatconsider the network at a much granular level. In conjunction with adistributed intelligence approach, a distributed data approach may bebeen adopted to facilitate data availability at all levels of thesolution through the use of database links and data services asapplicable. In this way, the solution for the historical data store(which may be accessible at the operations control center level 2116)may be similar to that of the operational data store.Historical/collective analytics may be performed at the operationscontrol center level 2116 by accessing data at INDE DEVICE level.Alternatively, data may be stored centrally at the INDE CORE 2120.However, given the amount of data that may need to be transmittedamongst the INDE DEVICES 2188, the storage of the data at the INDEDEVICES 2188 may be preferred. Specifically, if there are thousands ortens of thousands of sensors, the amount of data that needs to betransmitted to the INDE CORE 2120 may create a communicationsbottleneck.

Finally, the INDE CORE 2120 may program or control one, some or all ofthe INDE DEVICE 2188 in the network. For example, the INDE CORE 2120 maymodify the programming (such as download an updated program) or providea control command to control any aspect of the INDE DEVICE 2188 (such ascontrol of the sensors or analytics). Other elements, not shown in FIG.2, may include various integration elements to support this logicalarchitecture.

Table 2 describes the certain elements of INDE CORE 2120 as depicted inFIG. 21.

TABLE 2 INDE CORE Elements INDE CORE Description Element CEP Services2144 Provides high speed, low latency event stream processing, eventfiltering, and multi-stream event correlation Centralized May consist ofany number of commercial or custom Analytics analytics applications thatare used in a non-real time Applications 2139 manner, primarilyoperating from the data stores in INDE CORE. Visualization/ Support forvisualization of data, states and event Notification streams, andautomatic notifications based on event Services 2140 triggersApplication Services (such as Applications Support Services Management2142 and Distributed Computing Support 2143) that Services 2141 supportapplication launch and execution, web services, and support fordistributed computing and automated remote program download (e.g., OSGi)Network Automated monitoring of communications networks, Managementapplications and databases; system health Services 2145 monitoring,failure root cause analysis. Meta-Data Services (such as ConnectivityServices 2127, Name Services 2126 Translation 2128, and TEDS Service2129) for storage, retrieval, and update of system meta-data, includingcommunication/sensor net connectivity, point lists, sensor calibrations,protocols, device set points, etc Analytics Services (such as SensorData Services 2124 and Services 2123 Analytics Management Services 2125)to support access to sensor data and sensor analytics; management ofanalytics. Sensor Data Sensor data management system functions.Management System 2121 Real Time Message bus dedicated to handling eventmessage Complex Event streams—purpose of a dedicated bus it to provideProcessing Bus high bandwidth and low latency for highly bursty 2147event message floods. The event message may be in the form of XMLmessage. Other types of messages may be used. Events may be segregatedfrom operational/non- operational data, and may be transmitted on aseparate or dedicated bus. Events typically have higher priority as theyusually require some immediate action from an operational perspective(messages from defective vehicle equipment). The event processing bus(and the associated event correlation processing service depicted inFigure 21) may filter floods of events down into an interpretation thatmay better be acted upon by other devices. In addition, the eventprocessing bus may take multiple event streams, find various patternsoccurring across the multiple event streams, and provide aninterpretation of multiple event streams. In this way, the eventprocessing bus may not simply examine the event data from a singledevice, instead looking at multiple device (including multiple classesof devices that may be seemingly unrelated) in order to findcorrelations. The analysis of the single or multiple event streams maybe rule based Real Time Op/ Operational data may include data reflectingthe Non-Op Data current state of the particular industry network Non-Bus 2146 operational data may include data reflecting the “health” orcondition of a device. Operational data has previously been transmitteddirectly to a specific device (thereby creating a potential “silo”problem of not making the data available to other devices or otherapplications). However, using the bus structure, the operational datamay also be used for asset utilization/optimization, system planning,etc., Non-operational data was previously obtained by sending a personin the field to collect the operational data (rather than automaticallysending the non- operational data to a central repository). Typically,the operational and non-operational data are generated in the variousdevices in the grid at predetermined times. This is in contrast to theevent data, which typically is generated in bursts, as discussed below.A message bus may be dedicated to handling streams of operational andnon-operational data from substations and grid devices. The purpose of adedicated bus may be to provide constant low latency through put tomatch the data flows; as discussed elsewhere, a single bus may be usedfor transmission of both the operation and non- operational data and theevent processing data in some circumstances (effectively combining theoperation/non-operational data bus with the event processing bus).Operations Message bus that supports integration of typical Serviceindustry operations applications Bus 2130 The operations service bus2130 may serve as the provider of information about the smart grid tothe utility back office applications, as shown in FIG. 21. The analyticsapplications may turn the raw data from the sensors and devices on thegrid into actionable information that will be available to utilityapplications to perform actions to control the grid. Although most ofthe interactions between the utility back office applications and theINDE CORE 2120 is expected to occur thru this bus, utility applicationswill have access to the other two buses and will consume data from thosebuses as well (for example, meter readings from the op/non-op data bus2146, outage events from the event bus 2147) Sensor Data The sensor datawarehouse 2133 may provide rapid Warehouse 2133 access to sensor usagedata for analytics. This repository may hold all the sensor readinginformation from the sensors. The data collected from the sensors may bestored in sensor data warehouse 2133 and provided to otherapplications,) as well as other analysis. Event Logs 2135 Collection oflog files incidental to the operation of various industry systems. Theevent logs 2135 may be used for post mortem analysis of events and fordata mining Historical Data 2136 Telemetry data archive in the form of astandard data historian. Historical data 2136 may hold the time seriesnon-operational data as well as the historical operational data.Analytics pertaining to items like reliability, asset health, etc may beperformed using data in historical data 2136. Operational DataOperational Data 2137 may comprise a real time 2137 operationaldatabase. Operational Data 2137 may be built in true distributed form.Specifically, the Operational Data 2137 may hold data measurementsobtained from the sensors and devices. Historical data measurements arenot held in this data store, instead being held in historical data 2136.The data base tables in the Operational Data 2137 may be updated withthe latest measurements obtained from these sensors and devices.

As discussed in Table 2, the real time data bus 2146 (which communicatesthe operation and non-operational data) and the real time complex eventprocessing bus 2147 (which communicates the event processing data) intoa single bus 2346. An example of this is illustrated in the blockdiagram 2300 in FIGS. 23A-C.

As shown in FIGS. 21A-C, the buses are separate for performancepurposes. For CEP processing, low latency may be important for certainapplications which are subject to very large message bursts. Most of thegrid data flows, on the other hand, are more or less constant, with theexception of digital fault recorder files, but these can usually beretrieved on a controlled basis, whereas event bursts are asynchronousand random.

FIG. 21 further shows additional elements in the operations controlcenter 2116 separate from the INDE CORE 2120. Specifically, FIG. 21further shows Sensor Data Collection Head End(s) 2153, a system that isresponsible for communicating with meters (such as collecting data fromthem and providing the collected data to the utility). IP NetworkServices 2158 is a collection of services operating on one or moreservers that support IP-type communications (such as DHCP and FTP).Dispatch Mobile Data System 2159 is a system that transmits/receivesmessages to mobile data terminals in the field. Work Management System2150 is a system that monitors and manages work orders. GeographicInformation System 2149 is a database that contains information aboutwhere assets are located geographically and how the assets are connectedtogether. If the environment has a Services Oriented Architecture (SOA),Operations SOA Support 2148 is a collection of services to support theSOA environment.

One or more of the systems in the operations control center 2116 thatare outside of the INDE Core 2120 are legacy product systems that autility may have. Examples of these legacy product systems include theOperations SOA Support 2148, Sensor Data Collection Head End(s) 2153, IPNetwork Services 2158, and Dispatch Mobile Data System 2159. However,these legacy product systems may not be able to process or handle datathat is received from a smart grid. The INDE Core 2120 may be able toreceive the data from the smart grid, process the data from the smartgrid, and transfer the processed data to the one or more legacy productsystems in a fashion that the legacy product systems may use (such asparticular formatting particular to the legacy product system). In thisway, the INDE Core 2120 may be viewed as a middleware.

The operations control center 2116, including the INDE CORE 2120, maycommunicate with the Enterprise IT 2115. Generally speaking, thefunctionality in the Enterprise IT 2115 comprises back-officeoperations. Specifically, the Enterprise IT 2115 may use the enterpriseintegration environment bus 2114 to send data to various systems withinthe Enterprise IT 2115, including Business Data Warehouse 2104, BusinessIntelligence Applications 2105, Enterprise Resource Planning 2106,various Financial Systems 2107, Customer Information System 2108, HumanResource System 2109, Asset Management System 2110, Enterprise SOASupport 2111, Network Management System 2112, and Enterprise MessagingServices 2113. The Enterprise IT 2115 may further include a portal 2103to communicate with the Internet 2101 via a firewall 2102.

INDE DEVICE

The INDE DEVICE 2188 group may comprise any variety of devices used toprovide data associated with a particular device. In one example, thedevice group 2188 may include stationary sensor units 2190 and mobilesensor units 2192. Each stationary sensor unit 2190 and mobile sensorunit 2192 may include one or more sensors, processors, memory devices,communication modules, and/or power modules allowing receipt of any datafrom the sensors, as well as subsequent processing and/or transmissionof raw or processed sensor data. Raw or processed sensor data from thestationary sensor units 2190 and mobile sensor units 2192 may beprocessed by one or more gateways 2194. In one example, each gateway2194 may be one or more devices capable of encoding and transmittingdata to an operations control center 2116. Raw or processed sensor datafrom the stationary sensor units 2190 and the mobile sensor units 2192may also be provided to a data collector 2196. The data collector 2196may include one or more processors, memory devices, communicationmodules, and power modules. The data collector 2196 may be a memorydevice and processor configured to collect, store, and transmit data.The data collector 2196 may communicate with the stationary sensor units2190 and the mobile sensor units 2192 to collect data and transmitcollected data to one or more gateways 2194.

In one example, the stationary sensor units 2190 may detect conditionsassociated with one or more of the mobile sensor units 2192 or otherstationary sensor units 2190. The mobile sensor units 2192 may detectconditions associated with the stationary sensor units 2192 or maydetect other conditions associated with other mobile sensor units 2192.During operation, event data may be generated by the stationary sensorunits 2190 and the mobile sensor units 2192. The event data may beindicative of abnormal or undesired conditions of a vehicle travelnetwork. Such event data may be transmitted from the stationary sensorunits 2190 and the mobile sensor units 2192 through the gateways 2194 tothe central authority. In one example, event data may be received by arouting device 2189. The event data may be provided to the event bus2147 by the routing device 2189. The received event data may beprocessed by the operations control center 2116 to allow an appropriateresponse to be generated.

FIGS. 24A-24C is a block diagram of the INDE architecture to operatewith a rail travel network. The INDE system of FIGS. 24A-24B may receiveevent data from stationary sensor units 2190 and mobile sensor units2192 positioned on rail cars 2400 as shown in FIG. 25. In one example,the stationary sensor units 2190 and mobile sensor units 2192 may bethose disclosed in United States Patent Publication No. 2009/0173840,which is incorporated by reference herein.

Referring to FIG. 25, in one example, a freight train 2500 may includerail cars 2400 of various types such as box cars, cabooses, coal cars,engine cars, and any other car configured to be conveyed via rail. Theengine car 2502 may be powered by a diesel engine, battery, flywheel,fuel cell or any combination thereof. Each rail car 2400 may include oneor more mobile sensor units 2192. The mobile sensor units 2192 maycommunicate with one other allowing communication amongst mobile sensorunits 2192 of the same rail car 2400 or different rail cars 2400attached to the same string of rail cars 2400 or other rail cars 2400(not shown) detached from the string, such as those located in a trainyard. Each mobile sensor unit 2192 may have a unique ID and eachparticular rail car 2400 may have a unique ID maintained by each mobilesensor unit 2192 associated with the particular rail car 2400. The ID'smay be provided via RFID, for example.

In one example, the stationary sensor units 2190A may be configured toact as a “hot box” detector configured to monitor heating associatedwith a rail car wheels, axles, etc. The term “hot box,” as is known inthe art, may refer to a rail car experiencing overheating at one or moreaxle bearings and/or other wheel-based component on a piece of railwayrolling stock. Stationary sensor units 2190A may be placed alongrailroad tracks 2501. Each stationary sensor unit 2190A may be fittedwith one or more infrared (IR) sensors to determine heating patterns ofthe bearings/axles/wheels of the rail cars 2400 as the rail cars passthrough a sensing zone of a particular stationary sensor unit 2190A.Abnormal heating may indicate various issues such as rail car loadimbalance, rail car structural issues, track issues, etc. If anoverheated bearing is detected, a type of alarm can be triggered toalert the engineer to stop the train and correct the potentiallydangerous situation which, if allowed to continue, could result in atrain derailment. An example of a hot box detector is disclosed in U.S.Pat. No. 4,659,043, which is hereby incorporated by reference. Thestationary sensor units 2190A may be configured to process the IR sensordata to generate event data based on the alarm, such as event messages,to be received by the event bus 2147 for subsequent processing.

The stationary sensor units 2192B may also serve as a defect detector. Adefect detector may be a device used on railroads to detect axle andsignal problems in passing trains. The defect detectors can beintegrated into the rail tracks and may include sensors to detect one ormore kinds of problems that could occur. Defect detectors enablerailroads to eliminate the caboose at the rear of the train, as well asvarious station agents stationed along the route to detect unsafeconditions. The defect detector may be integrated or associated with awired or wireless transmitter. As trains pass the defect detectors, thedefect detector may output the railroad name, milepost or location,track number (if applicable), number of axles on the train that passedand the indication “no defects” to indicate that no problems weredetected on the train. Further, the location's ambient temperature andtrain speed may be output. When a problem is detected, the detector mayoutput an alarm indication, followed by a description of the problem andthe axle position within the train where the problem occurred.

The stationary sensor units 2190C may also be configured to act as a“silver boxes,” as is known in the art, configured to receive raw orprocessed data received by one or more stationary sensor units 2190A and2190B. The stationary sensor units 2192C may receive data from arespective group of stationary sensor units 2190A based on variouscommon factors, such as geographic location, for example. In thisregard, the stationary sensory units 2190C may be act as a datacollector 2196 as shown in FIGS. 21A-21C.

During operation, a train 2500 having a string of rail cars 2400 maytravel along rail tracks 2502. As the train 2500 travels, the stationarysensor units 2190A may detect information regarding each rail car 2400,such as bearing temperature. Each stationary sensor unit 2190A may alsocommunicate with each mobile sensor unit 2192. Communication may alloweach stationary sensor unit 2190A to perform a health check of each railcar 2400 and associated mobile sensor units 2192. Any indication ofabnormal or undesired conditions associated with a particular rail car2400 may be relayed to the stationary sensor units 2190C. Conditionsdetected may relate to rail car structure, rail car environment (e.g.,temperature), rail car content (e.g., weight, distribution, quantity,etc.), rail car motion, rail car position, or any other parameter ofinterest regarding a rail car 2400. The conditions detected may alsorelate to security, such as when a rail car door is opened, which mayindicate attempted theft or vandalism. The event data 2508 may be usedto alert a particular organization that may own a particular rail car.Thus, the operations control center 2116 may oversee an entire railwaynetwork, but companies owning individual rail cars 2400 may be alertedwhen an event data is transmitted regarding a particular rail car(s)2400 owned by a particular company. Alert messages may be provided viaan interface, subscription service, email, text message and/or any othercommunication manners capable of providing such alerts.

In one example, one of the rail cars 2400, such as the engine 2502, mayhave a mobile sensor unit 2192 serving as a master mobile sensor unit2504 to receive data from each mobile stationary unit 2192 associatedwith the rail cars 2400 of the current rail car string. When rail cars2400 are connected to form a particular train, each mobile sensor unit2192 may register with the master mobile sensor unit 2504. The mastermobile sensor unit 2504 may receive periodic or continuous streams ofraw or processed data from the mobile sensor units 2192. This allows theengineer to determine the health of each rail car 2400 during use.

In one example, each mobile sensor unit 2190 may include a globalpositioning system (GPS) module, allowing each individual mobile sensorunit 2192 to determine a respective geographic location. Each mobilesensor unit 2190 may receive GPS signals 2506 to determine geographiclocation. This information may be relayed to the stationary sensor units2192A when a particular rail car is within proximity to allowtransmission of such information. Each mobile sensor unit 2192 may,automatically or upon request, relay the geographic position to themaster mobile sensor unit 2504, which may be subsequently relayedthrough an onboard gateway 2194 to the operations control center 2116.In one example, the gateway 2194 may be that described in United StatesPatent Publication No. 2009/0173840. Each mobile senor unit 2192A mayalso wirelessly transmit a GPS signal, allowing each rail car 2400 to beindividually tracked. Such an arrangement may allow an entire train tobe tracked when only a single rail car has clear access to GPSsatellites, such as when a train is moving through a tunnel.

Each of the stationary sensor units 2190 and the mobile sensor units2192 may at least a part of the sensor data and generate an “event”. Theevent may comprise a no-incident event or an incident event. Theno-incident event may indicate that there is no incident (such as nofault) to report. The incident event may indicate that an incident hasoccurred or is occurring, such as a fault that has occurred or isoccurring in the section of the rail travel network.

The stationary sensor units 2190 and the mobile sensor units 2192 mayinclude one or both of: (1) intelligence to determine whether there isan incident; and (2) ability to take one or more actions based on thedetermination whether there is an incident. In particular, the memory inone or more of the stationary sensor units 2190 and the mobile sensorunits 2192 may include one or more rules to determine different types ofincidents based on the data generated by one or more sensors. Or, thememory in the stationary sensor units 2190 and the mobile sensor units2192 may include one or more look-up tables to determine different typesof incidents based on the data generated by one or more sensors.Further, the stationary sensor units 2190 and the mobile sensor units2192 may include the ability to take one or more actions based on thedetermination whether there is an incident.

Apart from working alone, the electronic elements in the rail travelnetwork may work together as part of the distributed intelligence of therail travel network. For example, stationary sensor units 2190 and themobile sensor units 2192 may share data or share processing power tojointly determine whether there is an incident and take one or moreactions based on the determination whether there is an incident.

The actions include, but are not limited to: (1) sending the incidentdetermination on the event bus 2147; (2) sending the incidentdetermination along with a recommended action on the event bus 2147; and(3) taking an action to modify the state of one or more sections of therail travel network or one or more vehicles traveling on the rail travelnetwork. For example, the stationary sensor units 2190 may control oneor more switches in a section of the rail travel network (such asredirecting traffic onto a separate rail line, open a lane for travel indifferent directions, etc.). Or, the stationary sensor units 2190 maymodify the parameters of one or more sensors in a section of the railtravel network (such as command the sensors to be more sensitive in itsreadings, command the sensors to generate more frequent readings, etc.).As still another example, the stationary sensor units 2190 and themobile sensor units 2192 may control one or more vehicles traveling onthe rail travel network. For example, a locomotive may include remotecommand-control capability, whereby the locomotive may be capable ofreceiving a wirelessly transmitted command to control one or moreaspects of the locomotive. The one or more aspects that the commandcontrols may include, but are not limited to, speed of the locomotive,generating a whistle (or other type of noise), and generating a light(or other type of visual indication). The receiver of the locomotive mayreceive the command and the processor of the locomotive may control oneor more aspects of the locomotive based on the command (such asmodifying operation of the engine).

The rail travel network may include distributed intelligence. Asdiscussed above, different stationary sensor units 2190 and the mobilesensor units 2192 within the rail travel network may include additionalfunctionality including additional processing/analytical capability anddatabase resources. The use of this additional functionality withinvarious stationary sensor units 2190 and the mobile sensor units 2192 inthe rail travel network enables distributed architectures withcentralized management and administration of applications and networkperformance. For functional, performance, and scalability reasons, arail travel network involving thousands of stationary sensor units 2190and the mobile sensor units 2192 may include distributed processing,data management, and process communications.

Non-operational data and operational data may be associated with andproximate to the stationary sensor units 2190 and the mobile sensorunits 2192. The stationary sensor units 2190 and the mobile sensor units2192 may further include components of the rail travel network that areresponsible for the observability of the rail travel network at varioussections. The stationary sensor units 2190 and the mobile sensor units2192 may provide three primary functions: operational data acquisitionand storage in the distributed operational data store; acquisition ofnon-operational data and storage in the historian; and local analyticsprocessing on a real time (such as a sub-second) basis. Processing mayinclude digital signal processing, detection and classificationprocessing, including event stream processing; and communications ofprocessing results to local systems and devices as well as to systems atthe operations control center 2116. Communication between the stationarysensor units 2190 and the mobile sensor units 2192 and other devices inthe rail travel network may be wired, wireless, or a combination ofwired and wireless. The electronic element may transmit data, such asoperation/non-operational data or event data, to the operations controlcenter 2116. A routing device may route the transmitted data to one ofthe operational/non-operational data bus or the event bus.

One or more types of data may be duplicated at the electronic elementand at the operations control center 2116, thereby allowing anelectronic element to operate independently even if the datacommunication network to the operations control center 2116 is notfunctional. With this information (connectivity) stored locally,analytics may be performed locally even if the communication link to theoperations control center 2116 is inoperative.

Similarly, operational data may be duplicated at the operations controlcenter 2116 and at the electronic elements. Data from the sensors anddevices associated with a particular electronic element may be collectedand the latest measurement may be stored in this data store at theelectronic element. The data structures of the operational data storemay be the same and hence database links may be used to provide seamlessaccess to data that resides on the electronic element thru the instanceof the operational data store at the operations control center 2116.This provides a number of advantages including alleviating datareplication and enabling data analytics, which is more time sensitive,to occur locally and without reliance on communication availabilitybeyond the electronic element. Data analytics at the operations controlcenter 2116 level may be less time sensitive (as the operations controlcenter 2116 may typically examine historical data to discern patternsthat are more predictive, rather than reactive) and may be able to workaround network issues if any.

Finally, historical data may be stored locally at the electronic elementand a copy of the data may be stored at the operations control center2116. Or, database links may be configured on the repository instance atthe operations control center 2116, providing the operations controlcenter access to the data at the individual electronic elements.Electronic element analytics may be performed locally at the electronicelement using the local data store. Specifically, using the additionalintelligence and storage capability at the electronic element enablesthe electronic element to analyze itself and to correct itself withoutinput from a central authority.

Alternatively, historical/collective analytics may also be performed atthe operations control center 2116 level by accessing data at the localelectronic element instances using the database links.

Further, various analytics may be used to analyze the data and/or theevents. One type of analytics may comprise spatial visualization.Spatial visualization ability or visual-spatial ability is the abilityto manipulate 2-dimensional and 3-dimensional figures. Spatialvisualization may be performed using one or more electronic elements, ormay be performed by the central authority. Further, spatialvisualization may be used with a variety of industry networks, includingutility networks and vehicle travel networks.

In one example, during operation, event data 2508 may be produced byeach mobile sensor unit 2192. The event data 2508 may be transmitted tothe master mobile sensor unit 2504. The master mobile sensor unit 2504may transmit the event data wirelessly from the gateway to theoperations control center 2116 for processing via a gateway 2194. Inalternative examples, each rail car 2400 may include a respectivegateway 2194 allowing data to be transmitted directly from the mobilesensor unit of the rail car 2400. This allows rail cars 2400 tocommunicate when not linked with an engine 2502, such as those beingstored in a train yard, to communicate event data 2508 to be received bythe operations control center 2116. In other alternative examples, eachtrain yard may have one or more stationary sensor units 2190 and gateway2194 to communicate with stored rail cars 2400 and to transmit any eventdata 2508. In a similar fashion, the stationary sensor units 2190A and2190B may transmit sensor data to the stationary sensor and event datathrough a similar gateway(s) 2194 to relay such information to theoperations control center 2116.

As described above, the network of FIGS. 24A-4C may also allowdistributed analysis such that event data 2508 is processed at thestationary sensor units 2190A and 2190B and at the master mobile sensormodule 2504. Such processing may allow for any issues to be analyzed andprovide a solution or course of action. Such issue solution may beconveyed may be used to automatically control the train 2500 any in anycapacity as the train 2500 is configured to allow or may alert humanoperators to control the train 2500 accordingly. The solution may alsobe conveyed to the operations control center 2116 allowing theoperations control center 2116 to perform actions remotely in order toconfirm the issue solution and implement the solution accordingly.

FIG. 26A-26C is a block diagram of an implementation of the INDEarchitecture related to an electric train network, such as a commutertrain. An electric train network may include one or more electric trainsthat may be powered overhead electric lines or third rail. In oneexample, an electric train 2600 may include one or more cars 2602. Eachcar may be individually powered by an external source (e.g., third railor overhead lines) or internal sources (e.g., battery or fuel cell).Each car may include one or more mobile sensor units 2192. Each mobilesensor unit 2192 may detect various conditions associated with variouspredetermined parameters of the train 2600.

In the example shown in FIGS. 26A-26C, the electric train 2600 may bepowered by a third rail 2604. The third rail 2604 may be connected toone or more stationary sensor modules 2192 that may monitor the powerflowing through the third rail 2604. The stationary sensor modules 2190may determine the health of the rail system and transmit any eventsrelated to abnormal, undesired, or status check in the form of eventmessages. The event messages may be transmitted by a gateway 2194 to bereceived by the operations control center 2116.

Each electric rail car 2602 may include one or more mobile sensor units2192. One of the mobile sensor units 2192 may serve as a master mobilesensor unit, such as the master mobile sensor unit 2504. The mobilesensor units 2192 may accumulate information regarding the respectiverail car in a fashion similar to that discussed with regard to FIGS.25A-5B. The master mobile sensor unit for the electric train 2600 mytransmit event messages generated by the other mobile sensor units 2192to the central authority via the gateway 2120.

FIGS. 27A-27C is a block diagram of an implementation of the INDEarchitecture applied to a road-based cargo transport network, such asthat used in the trucking industry. In one example, one or more mobilesensor units 2192 may be include in cargo containers 2700 such as thosehauled by diesel-engine trucks 2704. Each mobile sensor unit 2192 may besimilar to that of the mobile sensor units 2192 discussed with regard toFIGS. 25A-26C. Each mobile sensor unit 2192 may detect variousconditions of the cargo containers 2700 and relay them via an onboardgateway 2194 to the operations control center 2116. Stationary sensorunits 2190 may be distributed at customer facilities allowing cargo tobe checked using communication between the stationary sensor units 2190and the mobile sensor units 2192. The mobile sensor units 2192 may beused for cargo tracking, cargo container environment, theft/vandalismdetection and any other appropriate uses as described with regard toFIGS. 24A-25.

FIGS. 28A-28C is a block diagram of an implementation of the overallINDE architecture applied to a network of automobiles that may bepetroleum-fueled, electric, hybrid-fueled, bio-fueled or fueled by anyother suitable manner. In one example, a vehicle 2800 may include one ormore mobile sensor units 2192 allowing various conditions of the vehicle2800 to be monitored. Each vehicle may include a gateway 2194 orcommunicate through an external gateway 2194 to communicate event datadirectly to INDE core 120 or other mobile sensor units 2192. Similar toother examples discussed, the mobile sensor units 2192 may includedistributed intelligence that may perform analytics involved with thevehicle or may do so through interaction with INDE core 2120. Stationarysensor units 2190 may be used to communicate with the mobile sensorunits 2192 allowing evaluation of a vehicle 800 having a mobile sensorunit 2192 in proximity to communicate with stationary sensor units 190.The stationary sensor units 2190 may include or share a gateway 194allowing event data to be transmitted to the INDE CORE 2120 or maytransmit it directly to the INDE CORE 120. The stationary sensor units2190 may be implemented by car rental companies, car sales lots, orindividual owners to receive event data associated with the conditionand/or location of a vehicle 2800.

FIG. 30 shows an example of the INDE systems 2000 that may be remotelyhosted, as the block diagram illustrates. At a hosting site 3000,network cores 2002 may be installed as needed to support INDSsubscribers for a particular industry. In one example, as subscriber3002 may require use of various industries, such as rail, trucking, andairline. An INDE system 2000 may be modular allowing more industry typesto be added, or in alternative examples a new subscriber. A partyseparate from the electric utility may manage and support the softwarefor one, some, or all of the INDE systems 2000, as well as theapplications that are downloaded from the INDS hosting site to be usedfor system endpoints 2006 and system infrastructure 2008. In order tofacilitate communications, high bandwidth low latency communicationsservices, such as via network 3004 (e.g., a MPLS or other WAN), may beuse that can reach the subscriber utility operations centers, as well asthe INDS hosting sites.

While this invention has been shown and described in connection with thepreferred embodiments, it is apparent that certain changes andmodifications in addition to those mentioned above may be made from thebasic features of this invention. In addition, there are many differenttypes of computer software and hardware that may be utilized inpracticing the invention, and the invention is not limited to theexamples described above. The invention was described with reference toacts and symbolic representations of operations that are performed byone or more electronic devices. As such, it will be understood that suchacts and operations include the manipulation by the processing unit ofthe electronic device of electrical signals representing data in astructured form. This manipulation transforms the data or maintains itat locations in the memory system of the electronic device, whichreconfigures or otherwise alters the operation of the electronic devicein a manner well understood by those skilled in the art. The datastructures where data is maintained are physical locations of the memorythat have particular properties defined by the format of the data. Whilethe invention is described in the foregoing context, it is not meant tobe limiting, as those of skill in the art will appreciate that the actsand operations described may also be implemented in hardware.Accordingly, it is the intention of the Applicants to protect allvariations and modification within the valid scope of the presentinvention. It is intended that the invention be defined by the followingclaims, including all equivalents.

1. An integration framework for facilitating communication with acentral authority that manages an industry network, the integrationframework comprising: a first portion of a bus for communicatingoperational data to the central authority, the operational datacomprising a real-time measurement for at least a part of the industrynetwork; and a second portion of a bus for communicating event data tothe central authority, the second portion being separate from the firstportion, the event data being distinct from and derived from thereal-time measurement and comprising at least one analyticaldetermination based on the at least one real time measurement, whereinthe operational data is communicated via the first portion and notcommunicated via the second portion, and wherein the event data iscommunicated via the second portion and not communicated via the firstportion.
 2. The integration framework of claim 1, wherein the industrynetwork comprises a vehicle travel network.
 3. The integration frameworkof claim 2, wherein the vehicle travel network comprises a rail travelnetwork.
 4. The integration framework of claim 1, wherein the firstportion of the bus comprises a first segment and the second portion ofthe bus comprises a second segment, the first and second segments beingdifferent segments on the same bus.
 5. The integration framework ofclaim 4, further comprising at least one switch for analyzing at least apart of data received and for routing the data to one of the firstsegment and the second segment.
 6. The integration framework of claim 4,wherein the first portion of the bus comprises a first dedicated segmentdedicated exclusively to communicating the operational data; and whereinthe second portion of the bus comprises a second dedicated segmentdedicated exclusively to communicating the event data.
 7. Theintegration framework of claim 3, wherein the first portion of the buscomprises a first bus and the second portion of the bus comprises asecond bus, and wherein the first bus is physically separate from thesecond bus.
 8. The integration framework of claim 7, further comprisinga router for analyzing at least a part of data received and for routingthe data to one of the first bus and the second bus.
 9. The integrationframework of claim 8, wherein the router analyzes at least one header inthe data to determine whether to route the data to the first bus or tothe second bus.
 10. A data management system for an industry network anda central authority for managing the network, the utility networkcomprising a plurality of devices within the industry network, the datamanagement system comprising: data storage associated with a devicepositioned in a section of the network, the data storage being proximateto the device, the device sensing a parameter in the section of theindustry network, the data storage comprising a plurality of memorylocations for storing the sensed parameter; and a central data storageassociated with the central authority, wherein the central data storagecomprises links to the memory locations in the data storage.
 11. Thedata management system of claim 10, wherein the industry networkcomprises a vehicle travel network.
 12. The data management system ofclaim 11, wherein the vehicle travel network comprises a rail travelnetwork.
 13. An intelligent network for an industry system, theintelligent network comprising: at least one system endpoint comprising:a plurality of sensors configured to detect at least one aspectregarding the industry system and generate endpoint data indicative ofthe at least one aspect; and at least one endpoint analysis moduleconfigured to receive the endpoint data and generate a response based onthe endpoint data; a system infrastructure comprising: a plurality ofsensors configured to detect at least one aspect regardinginfrastructure of the industry system and generate infrastructure dataindicative of the at least one aspect; and at least one infrastructureanalysis module configured to receive the endpoint data and generate aresponse based on the endpoint data one or more data buses; and anetwork core configured to receive the endpoint data and theinfrastructure data through at least one or more of the data buses andgenerate a response based on at least one of the endpoint data and theinfrastructure data.
 14. The intelligent network of claim 13, whereinthe at least one endpoint analysis module is configured to determine theoccurrence of an event based on the endpoint data in the industry systemand determine at least one response based on the event.
 15. Theintelligent network of claim 13, wherein the at least one infrastructureanalysis module is configured to determine the occurrence of an eventbased on the infrastructure data in the industry system and determine atleast one response based on the event.
 16. The intelligent network ofclaim 13, wherein the at least one infrastructure module is configuredto: receive the endpoint sensor data; determine the occurrence of anevent based on the endpoint data in the industry system; and determineat least one response based on the event.
 17. The intelligent network ofclaim 13, wherein the network core is configured to determine eventbased on at least one of the endpoint data and the infrastructure dataand generate a response based on the at least one of the endpoint dataand the infrastructure data.
 18. The intelligent network of claim 13further comprising an enterprise system configured to communicate withthe network core.
 19. The intelligent network of claim 13, wherein theindustry system is a railway system.
 20. The intelligent network ofclaim 13, wherein the industry system is a trucking system.